Stlink: قم بتنظيف الكود بنوع متغير موحد

تم إنشاؤها على ٦ أبريل ٢٠٢٠  ·  6تعليقات  ·  مصدر: stlink-org/stlink

بقدر ما أستطيع أن أرى ، تستخدم العديد من الوظائف متغيرات ثابتة الطول. إنه مفيد حقًا للوظائف التي تحتاج إلى التعامل مع تنسيق بيانات ثابت. ومع ذلك ، فإن إساءة استخدام المتغيرات ذات الطول الثابت تسبب فشلًا محتملاً في البناء وقوالب غير ضرورية.

على سبيل المثال في src / usb.c:
image

send_recv اقبل txsize و rxsize كـ size_t ولكن في السياق الفعلي ، يجب تحويل هذه الوسائط إلى int أو unsigned int ، بدون طول ثابت ، ومن يسميه يقدم وسيطات من نوع مختلف ( uint32_t أو أرقام سحرية في هذه الحالة). يتم تطبيق الإرسال غير المقصود من 32 بت إلى 64 بت في عملية الاستدعاء. أيضًا ، لمنع فشل البناء ، هناك حاجة إلى العديد من القوالب الصريحة.

أقترح استبدال متغيرات الطول الثابت وفقًا لاستخداماتها الفعلية.
البقاء مشوشًا ليكون أكثر قابلية للحمل.

أود أن أجربها إذا وجدها الآخرون مفيدة.

codfeedback codrefactoring needissuer-feedback

ال 6 كومينتر

شكرا لطرح هذا على جدول الأعمال. نظرًا لأنها مشكلة عامة في جميع أنحاء قاعدة البيانات ، فأنا لست متأكدًا في الوقت الحالي مما إذا كان يجب علينا وضع ذلك في الإصدار 1.6.1 على الفور. طلب martonmiklos سابقًا إجراء بعض عمليات التنظيف المتعلقة بنمط الكود ، والذي دفعته إلى الإصدار 1.6.2. ربما يكون هذا مكانًا جيدًا لهذه المشكلة أيضًا ، على الرغم من أنها ستدفعها أبعد قليلاً.

ربما يمكنني القيام ببعض التنظيف محليًا أولاً ومتابعة عملية التطوير

حسنًا بالطبع يمكنك ذلك ، ولكن يُرجى التأكد من التفرع من develop واستمر في متابعة هذا الفرع ، بدلاً من master ، والذي لم يعد يُستخدم للتغييرات المتكررة ، ولكن فقط للإصدارات والإصلاحات العاجلة.

فيما يتعلق بالتوافق بين ILP32 و LLP64 و LP64 ، أعتقد أنه سيكون من الجيد استبدال نوع البيانات long بـ int32_t ، ولكن إذا أراد المرء استبعاد المفاجآت في المستقبل المتعلقة بـ التحويل ، قد نفكر في الانتقال إلى أنواع الأعداد الصحيحة ذات العرض الثابت كلما أمكن ذلك ...

chenguokai : سأترك هذا لك. يمكنك المساهمة ، إذا كنت ترغب في ذلك ولديك بعض الوقت.

بالتأكيد سأفعل ، قبل الإصدار. مشغول الآن

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات