بقدر ما أستطيع أن أرى ، تستخدم العديد من الوظائف متغيرات ثابتة الطول. إنه مفيد حقًا للوظائف التي تحتاج إلى التعامل مع تنسيق بيانات ثابت. ومع ذلك ، فإن إساءة استخدام المتغيرات ذات الطول الثابت تسبب فشلًا محتملاً في البناء وقوالب غير ضرورية.
على سبيل المثال في src / usb.c:
send_recv اقبل txsize
و rxsize
كـ size_t
ولكن في السياق الفعلي ، يجب تحويل هذه الوسائط إلى int
أو unsigned int
، بدون طول ثابت ، ومن يسميه يقدم وسيطات من نوع مختلف ( uint32_t
أو أرقام سحرية في هذه الحالة). يتم تطبيق الإرسال غير المقصود من 32 بت إلى 64 بت في عملية الاستدعاء. أيضًا ، لمنع فشل البناء ، هناك حاجة إلى العديد من القوالب الصريحة.
أقترح استبدال متغيرات الطول الثابت وفقًا لاستخداماتها الفعلية.
البقاء مشوشًا ليكون أكثر قابلية للحمل.
أود أن أجربها إذا وجدها الآخرون مفيدة.
شكرا لطرح هذا على جدول الأعمال. نظرًا لأنها مشكلة عامة في جميع أنحاء قاعدة البيانات ، فأنا لست متأكدًا في الوقت الحالي مما إذا كان يجب علينا وضع ذلك في الإصدار 1.6.1 على الفور. طلب martonmiklos سابقًا إجراء بعض عمليات التنظيف المتعلقة بنمط الكود ، والذي دفعته إلى الإصدار 1.6.2. ربما يكون هذا مكانًا جيدًا لهذه المشكلة أيضًا ، على الرغم من أنها ستدفعها أبعد قليلاً.
ربما يمكنني القيام ببعض التنظيف محليًا أولاً ومتابعة عملية التطوير
حسنًا بالطبع يمكنك ذلك ، ولكن يُرجى التأكد من التفرع من develop
واستمر في متابعة هذا الفرع ، بدلاً من master
، والذي لم يعد يُستخدم للتغييرات المتكررة ، ولكن فقط للإصدارات والإصلاحات العاجلة.
فيما يتعلق بالتوافق بين ILP32 و LLP64 و LP64 ، أعتقد أنه سيكون من الجيد استبدال نوع البيانات long
بـ int32_t
، ولكن إذا أراد المرء استبعاد المفاجآت في المستقبل المتعلقة بـ التحويل ، قد نفكر في الانتقال إلى أنواع الأعداد الصحيحة ذات العرض الثابت كلما أمكن ذلك ...
chenguokai : سأترك هذا لك. يمكنك المساهمة ، إذا كنت ترغب في ذلك ولديك بعض الوقت.
بالتأكيد سأفعل ، قبل الإصدار. مشغول الآن