[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Update of bug #34695 (project avr-libc): Priority: 1 - Later = 9 - Immediate ___ Follow-up Comment #8: This issue needs to be considered along with other stdint.h changes in bugs #36571, #35539. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Follow-up Comment #7, bug #34695 (project avr-libc): FYI, the attached files show avr-gcc's understanding of the C99 types with and without -mint8 You can use these defines as a blueprint for the stdin.h headers or use them directly (once a fix for http://gcc.gnu.org/PR46261 is upsteram). The advantage of using the types direcly like in #define int8_t __INT8_TYPE__ is that you don't need to bother with -mint8 on or off. Moreover, the definitions will be in sync with the compiler's implementation. The disadvantage is that you get more closely tied to the compiler and scanner's like link might easy going with open coded defines. (file #25969, file #25970) ___ Additional Item Attachment: File name: stdint-16.hSize:3 KB File name: stdint-mint8.h Size:2 KB ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Nachricht gesendet von/durch Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On 31/10/2011 22:29, Georg-Johann Lay wrote: Bob Paddock schrieb: All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. It is one of the most common Lints in commercial environments. But why clutter avr-libc with lint? You will have __attribute__((progmem)) from PROGMEM and PSTR macros __attribute__((signal)) from ISR macro __attribute__((interrupt)) for ISR code __attribute__((naked)) for custom startup/ISR bits __attribute__((OS_main)) AVR-specific __attribute__((OS_task)) AVR-specific __attribute__((noinline)) __attribute__((always_inline)) __attribute__((noclone)) __attribute__((const)) __attribute__((pure)) __attribute__((noreturn)) so you could just do #define __attribute__(...) or it's command line equivalent to get rid of all the messages. BTW: What will (sp)lint to with named address space qualifiers? Either it must be able to be told that there is special semantics or you end up dirscarding hundreds of potential RAM - Flask access failures when ignoring the qualifier. As far as avr-libc and -mint8 is concerned: Instead of messing with machine modes, it could do #if __INT_MAX__ == 127 typedef signed long int16_t; typedef signed int __attribute__((deprecated(no int32_t together with -mint8))) int32_t; ... #elif __INT_MAX__ == 32767 typedef signed int int16_t; typedef signed long int32_t; ... #else #error #endif or is there a reason why that do not work? Johann For -mint8, can you use long long int for int32_t? If so, it might be a better choice. As for lint, there is currently no general-purpose open source lint program that is worth the name. Splint has its uses, but it's a dead project, and has been for many years. Using it takes a lot of effort - you need to fill your code with manual annotations for it to be useful. I don't think it is worth spending much effort trying to make support for it. When I last looked at static analysis tools (which I do every now and again), my conclusions were: Splint is dead - it will never support modern C standards, and certainly not C++. Gimpel PC-Lint is /the/ standard tool in embedded development. It is commercial, but not too expensive for professionals (though the Linux version is three times the price!). It does a good job with unannotated code, and a better job with a few annotations. I don't know how it treats gcc-specific features such as __attribute__, or more modern C features such as memory spaces. But it is very much in active development, aiming to support C/C++ features that are in current use. I tested pclint a few years ago, but don't have a copy. It would be very useful to test avr-libc with PC-Lint (or equivalently, flexlint - their *nix version), and to support it with any required #ifdef's in the headers. But obviously that requires someone with the time to do the work, the money to buy a license, and the time to learn the tool. gcc itself is an excellent static error checker - the warnings get more powerful and more accurate with each release. I don't know how many warnings avr-libc developers usually use, but if anyone is working on static analysis compatibility with avr-libc, the emphasis should be on warning-free compilation with most warnings enabled in gcc. The nearest to an open-source general lint tool is perhaps http://clang-analyzer.llvm.org/. It is open source, and under heavy development, but it is still a work-in-progress. No C++ support as yet. It is sponsored by Apple, and thus geared towards Macs and Objective C, but aims to be more general purpose. cppcheck http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page is another open source checker tool. It is smaller in scope, but seems to be good at that job. A very useful feature of cppcheck is its strong integration with IDEs/editors (Code::Blocks, Codelite, and especially Eclipse). There are also several high-end commercial tools, and a whole range of special purpose open source tools (such as sparse), but these are seldom applicable to avr development. For my own use, I like /lots/ of warnings in gcc, and Eclipse with cppcheck. Many of the cppcheck checks are already found by Eclipse's built-in checker (which is very fast and convenient, but obviously only useful if you use Eclipse) and/or gcc - but some checks are still useful. I haven't found any need to do anything special to get warning-free checking using that setup for avr-gcc and avr-libc. But I haven't tried compiling or checking avr-libc itself. mvh., David ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Just to make clear for some of us all code must be passed through Lint as part of our procedures and any exclusions have to be justified. The avr compiler though very good does bring up a number of errors which have to be optioned out some because of the unusual bracketing used in the compiler. A sample of Lint exceptions due to the compiler is shown below. (This is the Gimpel PC-Lint referred to by David Brown). It should also be remembered that compiler versions tend to have a long life, in industry, as updating has quality on our backs wanting justification and proof that the updated compiler is suitable for the job. Keep up the good work, it's much appreciated. David -esym(1065, __vector_?, __vector_??) // Not declared as 'C' (For __vector_n()) -esym(762, __vector_?, __vector_??) // Redundant declaration (For __vector_n()) -esym(765, __vector_?, __vector_??, start_of_pool, timebaseTicksFromStart) // Could be made static (For __vector_n()) -esym(714, __vector_?, __vector_??) // Not referenced (For __vector_n()) -esym(551, pwm) // Not accessed (not true Lint just can't discern use) -esym(950, _to_brackets, _to_semi) // Compiler macros //-emacro(40, __asm__, cli, sei, cbi, sbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) //-emacro(10, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) -emacro(123, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) //-emacro(522, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) //-emacro(515, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) //-emacro(523, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) //-emacro(911, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) //-emacro(923, __asm__, cli, sei, sei, cbi, bit_is_set, bit_is_clear, loop_until_bit_is_set, loop_until_bit_is_clear, sleep_mode, _BV) // Register macros specified for compiler -emacro(915, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??) -emacro(921, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??) -emacro(923, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??) -emacro(925, OCR??, TCCR??, TCNT?, ETIMSK, ETIFR, PORT?, PORT??, PIN?, PIN??) -Original Message- From: avr-libc-dev-bounces+dbreeze=joy.co...@nongnu.org [mailto:avr-libc-dev-bounces+dbreeze=joy.co...@nongnu.org] On Behalf Of David Brown Sent: 01 November 2011 08:50 To: Georg-Johann Lay Cc: avr-libc-dev@nongnu.org Subject: Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__() On 31/10/2011 22:29, Georg-Johann Lay wrote: Bob Paddock schrieb: All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. It is one of the most common Lints in commercial environments. But why clutter avr-libc with lint? You will have __attribute__((progmem)) from PROGMEM and PSTR macros __attribute__((signal)) from ISR macro __attribute__((interrupt)) for ISR code __attribute__((naked)) for custom startup/ISR bits __attribute__((OS_main)) AVR-specific __attribute__((OS_task)) AVR-specific __attribute__((noinline)) __attribute__((always_inline)) __attribute__((noclone)) __attribute__((const)) __attribute__((pure)) __attribute__((noreturn)) so you could just do #define __attribute__(...) or it's command line equivalent to get rid of all the messages. BTW: What will (sp)lint to with named address space qualifiers? Either it must be able to be told that there is special semantics or you end up dirscarding hundreds of potential RAM - Flask access failures when ignoring the qualifier. As far as avr-libc and -mint8 is concerned: Instead of messing with machine modes, it could do #if __INT_MAX__ == 127 typedef signed long int16_t; typedef signed int __attribute__((deprecated(no int32_t together with -mint8))) int32_t; ... #elif __INT_MAX__ == 32767 typedef signed int int16_t; typedef signed long int32_t; ... #else #error #endif or is there a reason why that do not work? Johann For -mint8, can you use long long int for int32_t? If so, it might be a better choice. As for lint, there is currently no general-purpose open source lint program that is worth the name. Splint has its uses, but it's a dead project, and has been for many years
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On Tue 01 Nov 2011 02:12:17 NZDT +1300, Weddington, Eric wrote: Eric, what changes are you thinking of for better lint-friendliness? I was hoping you could tell me. ;-) Back to me then ;-) I had already posted my solution. To recap, the problem is parsing typedef int int8_t __attribute__((__mode__(__QI__))); typedef int int16_t __attribute__((__mode__ (__HI__))); typedef int int32_t __attribute__((__mode__ (__SI__))); with any standards-compliant parser. Crikey - what a mountain of syntax errors. Let's fix the abberration (but still allow this to compile with gcc) by including first #ifndef __GNUC__ #define __attribute__(dumpit) #endif At which point one is left with typedef int int8_t; typedef int int16_t; typedef int int32_t; not knowing whether to groan, shake head, or just laugh. So my suggestion (and attached patch) was to define these such that they *ALSO* work when the __attribute__ part is cpp'ed away. Johann suggested to look at INT_MAX to get the typedefs right. For orientation, glibc and newlib don't have that problem, but also don't use __QI__ etc. to define them. I am not objecting to using the quantum mechanism to define the int types for gcc, I am objecting to the nonsense in front of that. So far no-one has said whether this breaks anything. But I don't want to spend any more time on this. I'll just fix my own copy. Greetings, Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
As Volker Kuhlmann wrote: I had already posted my solution. To recap, the problem is parsing typedef int int8_t __attribute__((__mode__(__QI__))); typedef int int16_t __attribute__((__mode__ (__HI__))); typedef int int32_t __attribute__((__mode__ (__SI__))); with any standards-compliant parser. And we already made it clear that we won't change *actual code* that has been proven to work well for years, just for the sake of satisfying whatever analysis tool being used. What's next? Are you going to tell us to not use inline assembly statements, because they are non-standard, and your analyser doesn't grok them? Are you going to tell us that __extension__ is evil and must be avoided? This is a *system* library, and it is meant for just one compiler (AVR-GCC), so we completely reserve the right to implement it in the most efficient way we see fit GCC can handle. However, what we are going to accept is patches that make the library more lint friendly. For that, everything has to be wrapped in #ifdef LINT (or #ifdef lint - I wouldn't care, but users should agree on one of them), so preprocessing it without LINT being defined yields the same code as before. I am not objecting to using the quantum mechanism to define the int types for gcc, I am objecting to the nonsense in front of that. With the wording you are choosing, you won't convince anyone. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On 01/11/2011 11:28, Joerg Wunsch wrote: As Volker Kuhlmann wrote: I had already posted my solution. To recap, the problem is parsing typedef int int8_t __attribute__((__mode__(__QI__))); typedef int int16_t __attribute__((__mode__ (__HI__))); typedef int int32_t __attribute__((__mode__ (__SI__))); with any standards-compliant parser. And we already made it clear that we won't change *actual code* that has been proven to work well for years, just for the sake of satisfying whatever analysis tool being used. What's next? Are you going to tell us to not use inline assembly statements, because they are non-standard, and your analyser doesn't grok them? Are you going to tell us that __extension__ is evil and must be avoided? This is a *system* library, and it is meant for just one compiler (AVR-GCC), so we completely reserve the right to implement it in the most efficient way we see fit GCC can handle. However, what we are going to accept is patches that make the library more lint friendly. For that, everything has to be wrapped in #ifdef LINT (or #ifdef lint - I wouldn't care, but users should agree on one of them), so preprocessing it without LINT being defined yields the same code as before. While I agree with your principle here, I think there is good reason for changing the typedefs in this case - and nothing to lose. People use different tools with their code, such as static error checkers, documentation generators, and smart editors like Eclipse. They also sometimes read the files. The use of __attribute__((__mode__)) as the sole way to define sizes seems to me to be gratuitously non-standard. I am all in favour of using non-standard constructs or extensions when they are a help - making source code clearer, shorter or more readable, letting the compiler generate smaller or faster object code, or simply implementing features that can't be expressed in standard C. But this is not such a case. I appreciate don't change something that works as a good reason for leaving the typedefs as they are. But you have to weigh that against changing it to something clearer and standard, easier to read, easier to maintain (not that there is likely to be many changes), and easier to use with other tools. It is even more ironic that there are already standard definitions in stdint.h precisely to support tools other than avr-gcc, namely doxygen. I also wonder if there are differences in the way gcc treats mode attribute definitions from standard definitions. In particular, in C a unsigned char is /not/ identical to an 8-bit unsigned int. The unsigned char has different aliasing properties than an unsigned int of any size. Will code that relies on the these aliasing properties work correctly with uint8_t as defined in avr-libc? And will it /always/ work correctly, with future versions of avr-gcc? mvh., David I am not objecting to using the quantum mechanism to define the int types for gcc, I am objecting to the nonsense in front of that. With the wording you are choosing, you won't convince anyone. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__(mode)
David Brown a écrit: While I agree with your principle here, I think there is good reason for changing the typedefs in this case - and nothing to lose. People use different tools with their code, such as static error checkers, documentation generators, and smart editors like Eclipse. They also sometimes read the files. The use of __attribute__((__mode__)) as the sole way to define sizes seems to me to be gratuitously non-standard. I am all in favour of using non-standard constructs or extensions when they are a help - making source code clearer, shorter or more readable, letting the compiler generate smaller or faster object code, or simply implementing features that can't be expressed in standard C. But this is not such a case. -mint8 is non-standard C I also wonder if there are differences in the way gcc treats mode attribute definitions from standard definitions. In particular, in C a unsigned char is /not/ identical to an 8-bit unsigned int. The unsigned char has different aliasing properties than an unsigned int of any size. Will code that relies on the these aliasing properties work correctly with uint8_t as defined in avr-libc? And will it /always/ work correctly, with future versions of avr-gcc? Aliasing is a good point. But as the moment discussing -mint8 features is void because that feature is broken some time now (PR46261). Johann ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__(mode)
On 01/11/2011 13:10, Georg-Johann Lay wrote: David Brown a écrit: While I agree with your principle here, I think there is good reason for changing the typedefs in this case - and nothing to lose. People use different tools with their code, such as static error checkers, documentation generators, and smart editors like Eclipse. They also sometimes read the files. The use of __attribute__((__mode__)) as the sole way to define sizes seems to me to be gratuitously non-standard. I am all in favour of using non-standard constructs or extensions when they are a help - making source code clearer, shorter or more readable, letting the compiler generate smaller or faster object code, or simply implementing features that can't be expressed in standard C. But this is not such a case. -mint8 is non-standard C Correct. I also wonder if there are differences in the way gcc treats mode attribute definitions from standard definitions. In particular, in C a unsigned char is /not/ identical to an 8-bit unsigned int. The unsigned char has different aliasing properties than an unsigned int of any size. Will code that relies on the these aliasing properties work correctly with uint8_t as defined in avr-libc? And will it /always/ work correctly, with future versions of avr-gcc? Aliasing is a good point. It is subtle issues like this that worry me - they are hard to spot, hard to test, and /very/ difficult to debug if they affect users code. I am not saying that the use of mode gets aliasing wrong - just that we should be very sure that it gets it right if the typedefs are not standardised. gcc gets cleverer every release - but that also makes it more and more important for users to understand the nuances of the C standards, and for the tools to work perfectly according to those standards. Otherwise the compiler and the user and going to be making different assumptions, and things break in mysterious ways. The other possible issue that springs to mind is debuggers - will debuggers always be happy with non-standard definitions of the types? But as the moment discussing -mint8 features is void because that feature is broken some time now (PR46261). Johann Could -mint8 be removed entirely? It would simplify some library code (such as stdint.h), and would no doubt simplify things in the compiler. I know gcc always likes to have a deprecation period before removing features, but doesn't hasn't worked for some time. As far as I can tell, the main reason for not removing -mint8 is that people used it to get the smallest possible code, since there were a number of missed optimisations due to 8-bit to 16-bit integer promotion. But many of these have been fixed, or at least greatly improved, in gcc 4.7 (thanks especially to Johann, I believe). mvh., David ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__(mode)
As David Brown wrote: The other possible issue that springs to mind is debuggers - will debuggers always be happy with non-standard definitions of the types? At least GDB apparently doesn't have a problem, and very likely the AVR Studio (4 5) debuggers neither. Otherwise, we'd already knew about it. ;-) The point here is certainly that the debuggers don't see the actual typedef at all, but only their attributes (signedness, size in bytes) as part of the debugging information. Could -mint8 be removed entirely? I wouldn't like it until the day when all the minor integer promotion issues with 8-bit arithmetics have been sorted out. (such as stdint.h), and would no doubt simplify things in the compiler. For the compiler, the policy has been to not actively spend much time into it, but to not break it without need. But many of these have been fixed, or at least greatly improved, in gcc 4.7 (thanks especially to Johann, I believe). Yes, and that will hopefully make my concerns from above void some not too distant day. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On 01/11/2011 13:45, Joerg Wunsch wrote: As David Brown wrote: It is even more ironic that there are already standard definitions in stdint.h precisely to support tools other than avr-gcc, namely doxygen. OK, so what's wrong with writing #if defined(__DOXYGEN__) || defined(LINT) then? That might be okay. However, why not do this: #if defined(__DOXYGEN__) #define __attribute__(discard) #endif Then you can have a single set of definitions: typedef unsigned char uint8_t __attribute__((__mode__(__QI__))); typedef unsigned int uint16_t __attribute__((__mode__(__HI__))); typedef unsigned long int uint32_t __attribute__((__mode__(__SI__))); #if !__USING_MINT8 typedef unsigned long int uint64_t __attribute__((__mode__(__DI__))); #endif This means your real-world definitions are the same as the DOXYGEN ones (always a good idea, if possible). Tools that don't like __attribute__ will get the correct sizes, except in the odd case of people using -mint8 (which is already asking for trouble with third-party tools, since it is not standard C). avr-gcc will always see the correct size, even with -mint8, since the mode attributes will override the sizes of the types. Surely that would keep everyone happy? In particular, in C a unsigned char is /not/ identical to an 8-bit unsigned int. The unsigned char has different aliasing properties than an unsigned int of any size. In which respect? A char * can alias any other type, but an int * cannot - it will only alias compatible types (signed and unsigned ints, const versions, etc.). I'm a little unclear about whether it is only plain char* and unsigned char* that have this aliasing property, or if it also applies to signed char* (I've seen conflicting references). But the use of mode-sized ints opens up two possible issues: If 8-bit QI int does not alias any type (other than compatible ones), then code that relies on aliasing will be incorrect. On the other hand, it may be that the different mode-sized int types will all alias each other, and standard int (and compatible types). This could then lead to less optimal code. It may also be that a 32-bit mode-size int would not alias a normal long int, which could again lead to incorrect code. It is not very often that the aliasing rules actually influence the generated code. But it /can/ happen, and it is very important that they are correct - and that they are guaranteed to stay correct with future versions of the compiler. Someone familiar with the insides of gcc may be able to give a definitive answer here, but I would feel happier using standard types for the typedefs - then we are definitely on safe ground. mvh., David ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
As David Brown wrote: That might be okay. However, why not do this: #if defined(__DOXYGEN__) #define __attribute__(discard) #endif I don't know whether doxygen's preprocessing stage will really work correctly with that. Otherwise, it might be fine. A char * can alias any other type, but an int * cannot - it will only alias compatible types (signed and unsigned ints, const versions, etc.). I'm a little unclear about whether it is only plain char* and unsigned char* that have this aliasing property, or if it also applies to signed char* (I've seen conflicting references). As per the C standard rationale, signedness considerations have been kept out of any aliasing rules. The char has been chosen simply because char pointers have historically been used a lot to address arbitrary bytes which are actually parts of larger objects. Since (u)int8_t types are not described by the standard to also offer this feature, you are technically not allowed to use pointers to these types to alias parts of a larger object -- even though this leads to the somewhat stupid situation that you have to resort to an `unsigned char *' again for this, where you cannot be really sure (without other checks) that the object it points to is really exactly 8 bits wide. In practice, I don't think you'll observe any different behaviour between an `unsigned char' and an `uint8_t' with GCC, unless (obviously) working on a platform that does not offer 8-bit integers at all (but I don't know whether such a platform exists where GCC has ever been ported to). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On 01/11/2011 15:14, Joerg Wunsch wrote: As David Brown wrote: That might be okay. However, why not do this: #if defined(__DOXYGEN__) #define __attribute__(discard) #endif I don't know whether doxygen's preprocessing stage will really work correctly with that. Otherwise, it might be fine. A char * can alias any other type, but an int * cannot - it will only alias compatible types (signed and unsigned ints, const versions, etc.). I'm a little unclear about whether it is only plain char* and unsigned char* that have this aliasing property, or if it also applies to signed char* (I've seen conflicting references). As per the C standard rationale, signedness considerations have been kept out of any aliasing rules. That certainly seems to be the case in gcc, at least according to the user documents: http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Optimize-Options.html#index-fstrict_002daliasing-721 The reason I questioned the signed char case was from a quotation from the standards in a stackoverflow question, which suggests that it only applies to plain char and unsigned char. I don't have a copy of the standards on-hand to check. It may also be that it applies only to C++, not C. http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule/7005988#7005988 The char has been chosen simply because char pointers have historically been used a lot to address arbitrary bytes which are actually parts of larger objects. Since (u)int8_t types are not described by the standard to also offer this feature, you are technically not allowed to use pointers to these types to alias parts of a larger object -- even though this leads to the somewhat stupid situation that you have to resort to an `unsigned char *' again for this, where you cannot be really sure (without other checks) that the object it points to is really exactly 8 bits wide. I hadn't thought of it that way, but you might be right here. Of course, there are targets where uint8_t does not exist, and uint16_t (or even uint32_t) is an unsigned char and has the alias-anything properties. But I think it is impossible in standard C (i.e., not using the mode attributes) to get a uint8_t without it being an unsigned char - thus it is normally considered safe to rely on its aliasing properties. My concern is just with any possible differences between a mode-defined 8-bit int and a char. In practice, I don't think you'll observe any different behaviour between an `unsigned char' and an `uint8_t' with GCC, unless (obviously) working on a platform that does not offer 8-bit integers at all (but I don't know whether such a platform exists where GCC has ever been ported to). I can't think of any such platforms. Most targets that don't have 8-bit chars are either dinosaur mainframes, or particularly annoying DSPs. AFAIK, the DSPs that gcc supports (such as as the Blackfin) have 8-bit chars (though they might have 32-bit int_fast8_t). ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
As David Brown wrote: The reason I questioned the signed char case was from a quotation from the standards in a stackoverflow question, which suggests that it only applies to plain char and unsigned char. I don't have a copy of the standards on-hand to check. It may also be that it applies only to C++, not C. I don't know about the C++ standard, but the C standard explicitly states: 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types:74) ... -- a character type. 74) The intent of this list is to specify those circumstances in which an object may or may not be aliased. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Joerg Wunsch schrieb: OK, so what's wrong with writing #if defined(__DOXYGEN__) || defined(LINT) then? LINT is the wrong name space; should be __LINT or _LINT ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On Mon 31 Oct 2011 02:04:10 NZDT +1300, Bob Paddock wrote: Their system won't allow a direct link. Click on view messages at the bottom left. There are several related discussions: Normally it is sufficient to use ++d__attribute__(p)= And be sure to use '-wlib(1)', not '-wlib(0)'. That way you will be alerted to misunderstood syntax in the header files. This seems to have done the trick: +rw(_to_brackets) -d__attribute__=_to_brackets All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Follow-up Comment #5, bug #34695 (project avr-libc): Eric, what changes are you thinking of for better lint-friendliness? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. It is one of the most common Lints in commercial environments. ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
-Original Message- From: Volker Kuhlmann [mailto:invalid.nore...@gnu.org] Sent: Monday, October 31, 2011 4:16 AM To: Volker Kuhlmann; Joerg Wunsch; Weddington, Eric; avr-libc- d...@nongnu.org Subject: [bug #34695] fixed width int types without __attribute__() Follow-up Comment #5, bug #34695 (project avr-libc): Eric, what changes are you thinking of for better lint-friendliness? I was hoping you could tell me. ;-) ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Bob Paddock schrieb: All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. It is one of the most common Lints in commercial environments. But why clutter avr-libc with lint? You will have __attribute__((progmem))from PROGMEM and PSTR macros __attribute__((signal)) from ISR macro __attribute__((interrupt)) for ISR code __attribute__((naked)) for custom startup/ISR bits __attribute__((OS_main))AVR-specific __attribute__((OS_task))AVR-specific __attribute__((noinline)) __attribute__((always_inline)) __attribute__((noclone)) __attribute__((const)) __attribute__((pure)) __attribute__((noreturn)) so you could just do #define __attribute__(...) or it's command line equivalent to get rid of all the messages. BTW: What will (sp)lint to with named address space qualifiers? Either it must be able to be told that there is special semantics or you end up dirscarding hundreds of potential RAM - Flask access failures when ignoring the qualifier. As far as avr-libc and -mint8 is concerned: Instead of messing with machine modes, it could do #if __INT_MAX__ == 127 typedef signed long int16_t; typedef signed int __attribute__((deprecated(no int32_t together with -mint8))) int32_t; ... #elif __INT_MAX__ == 32767 typedef signed int int16_t; typedef signed long int32_t; ... #else #error #endif or is there a reason why that do not work? Johann ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
URL: http://savannah.nongnu.org/bugs/?34695 Summary: fixed width int types without __attribute__() Project: AVR C Runtime Library Submitted by: vok Submitted on: Sun 30 Oct 2011 21:06:15 NZDT Category: Header Severity: 3 - Normal Priority: 5 - Normal Item Group: Header files Status: None Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Release: 1.7.1 Fixed Release: None ___ Details: The eclipse 3.7.1 code analyser throws heaps of errors because it doesn't parse __attribute__(), and then doesn't find methods because it thinks they're different because their arguments don't match. For example unsigned char would be compatible with uint8_t, except it's typedef'd as unsigned int when __attribute__() is ignored. Change typedefs to give a correct result even without __attribute__(), which is ignored by gcc but does matter elsewhere. Without having tried I'd expect the same problem with lint. ___ File Attachments: --- Date: Sun 30 Oct 2011 21:06:15 NZDT Name: avr-libc-1.7.1_stdint.diff Size: 1kB By: vok http://savannah.nongnu.org/bugs/download.php?file_id=24247 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Follow-up Comment #2, bug #34695 (project avr-libc): On a second thought: generally preparing our header files for being more lint-friendly might be a good idea. Everything should be wrapped within #ifdef __lint where needed. This should in particularly consider the commonly used splint utility, but if Eclipse is using something differently, this could be covered as well. Btw., IIRC, the attribute-based integer types have been introduced since they are completely unaffected by the -mint8 compiler option. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Follow-up Comment #3, bug #34695 (project avr-libc): The trivial way to deal with lint (its splint incantation or whichever other one) is to use run lint with -DLINT and to use this in code: #ifdef LINT #define __attribute__(discard) #endif lint will for sure only grok standard C, which __attribute__ is not. I don't know what parser eclipse uses but my feeling is it has its own. Obviously it's able to ignore __attribute__, and it's entirely within its right to ignore it altogether. eclipse supports any compiler, so why should it learn about every proprietary extension? The good reasons gcc uses the attribute-based information are irrelevant here, fact is it does, and fact is avr-libc falls flat on its face with anything but gcc. Are there any drawbacks with declaring those types in a way that would still work if __attribute__ was absent? Because if not, not doing so is just stubborn but not helpful when there are advantages in doing so. Just because you can put any standard int type in there (because gcc ignores it anyway) doesn't mean you should. I don't much care about -mint8, it seems well on its way to the scrap heap of seemed like a good idea at the time, so I'm in favour of fixing things for the absence of -mint8 (or for both if -mint8 can be tested for in an #ifdef). ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
On Sun, Oct 30, 2011 at 6:37 AM, Volker Kuhlmann invalid.nore...@gnu.org wrote: _attribute_ For Gimpel Lint search for _attribute_ here: http://www.gimpel.com/Discussion.cfm?action=search Their system won't allow a direct link. There are several related discussions: Normally it is sufficient to use ++d__attribute__(p)= And be sure to use '-wlib(1)', not '-wlib(0)'. That way you will be alerted to misunderstood syntax in the header files. This seems to have done the trick: +rw(_to_brackets) -d__attribute__=_to_brackets ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()
Update of bug #34695 (project avr-libc): Severity: 3 - Normal = 1 - Wish Priority: 5 - Normal = 1 - Later ___ Follow-up Comment #4: I would also like to remind our users that avr-libc is part of the overall GCC-based toolchain for the AVR, which includes: - GNU Binutils (assembler, linker, utilities) - GCC - avr-libc - GDB The Eclipse code analyzer tool is not necessarily an official part of that toolchain. I agree in that, technically, the Eclipse-based tool needs to be taught GCC's extensions, especially attributes. But, I can also agree with Joerg in that making avr-libc's more lint-friendly might be a good idea too. My only personal caveat is that this is something that is low priority for the avr-libc developers/maintainers. (We already have enough changes planned in the future for the header files.) I would be willing to accept outside patches to do this, if they are shown to be useful and don't break avr-libc. I'm lowering the Priority and Severity accordingly. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?34695 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
