- Is this safe? - 6 Updates
| Muttley@dastardlyhq.com: Feb 27 08:43AM On Sat, 25 Feb 2023 19:13:47 +0100 >The check is in the compiler. But it is not part of the printf function >- which is not built into the compiler in any way, and is not used in >Scott's code here. So how does putting "format(printf" there work if it doesn't know about printf? |
| Muttley@dastardlyhq.com: Feb 27 08:44AM On Sat, 25 Feb 2023 19:15:37 +0100 >write good quality code that works correctly, great. I haven't seen >much evidence so far of you having any ability to learn, but I'll keep >hoping. So you generally don't bother doing array bounds checking and you patronise me about not being able to write good code?? Please, look in the mirror sometime when you get a chance. |
| David Brown <david.brown@hesbynett.no>: Feb 27 10:31AM +0100 >> - which is not built into the compiler in any way, and is not used in >> Scott's code here. > So how does putting "format(printf" there work if it doesn't know about printf? You misunderstand. A compiler can /know/ about a standard library function, without having an /implementation/ of it. An actual implementation of "printf" is in not "built in" to gcc (or any other compiler that I have seen). But a knowledge of the specification of "printf" might be. The compiler has no idea where the output of "printf" ends up, or how it will get there - that is up to the library that implements printf, the OS that runs the program, and many other factors. But it /does/ know that if you call printf with the format string "%i%s", then you need two extra parameters - the first one of which is an "int" (after default promotion for variadic functions), and the second one is a string. So a compiler can check that you have the right parameters to "printf" even if the function is not built into the compiler. In particular with the case of gcc, the compiler has a checking feature for printf-style format strings (and scanf, and a couple of other formats). The declaration of "printf" in <stdio.h> in standard libraries used with gcc will have "__attribute__((format(printf..." in their declaration. The parameter type checking is built into the compiler, the function implementation is not. (gcc has knowledge of a few other aspects of printf and friends - sometimes it can figure out optimisations in a certain specific cases. It might know, for example, some relations between varieties like fprintf and printf, and it tries to do some buffer size checks on sprintf and snprintf. But for anything non-trivial, it calls the external library function to do the real work.) |
| David Brown <david.brown@hesbynett.no>: Feb 27 10:40AM +0100 >> hoping. > So you generally don't bother doing array bounds checking and you patronise > me about not being able to write good code?? Yes. I write efficient code for small devices. Why should I waste processor time checking something that I know is correct? Good programming involves splitting tasks into subtasks, where each subtask will do its own job. Subtasks, or functions, will have specifications - sometimes written out explicitly, sometimes (especially for small local functions) obvious. Every function can assume its preconditions are satisfied when it is called - it is the job of the /calling/ function to get that right. Having each bit of code doing the job of other bits of code is just a waste of everyone's time and effort, and leads to pointless redundancy (not useful redundancy) and untestable and unmaintainable code. And it encourages others to do a bad job - the guy writing the calling function can be lazy because he thinks the called function will do all the work. I don't do array bounds checking. I write code that accesses arrays with the index value that is correct for the requirements of the program - additional checks are therefore worse than useless. |
| Muttley@dastardlyhq.com: Feb 27 10:24AM On Mon, 27 Feb 2023 10:40:55 +0100 >I don't do array bounds checking. I write code that accesses arrays >with the index value that is correct for the requirements of the program >- additional checks are therefore worse than useless. I wonder how many C programmers thought that only to see their masterpiece die in a heap? Unless you're only doing array access in a loop up to array size or via literals then I suspect your code will come unstuck one day. |
| David Brown <david.brown@hesbynett.no>: Feb 27 06:31PM +0100 > die in a heap? > Unless you're only doing array access in a loop up to array size or via literals > then I suspect your code will come unstuck one day. I suspect you haven't a clue about how I work and what my code does. I suspect you have never learned anything about serious programming, but merely had a few courses in C and C++ - that would explain why you don't understand basic concepts such as specifications. I could be wrong, of course - maybe you have had decent courses but did not understand them, or simply think that you know better than others. In the meantime, I will continue to write code that does what it is specified to do. Of course I make mistakes sometimes, and have to find and fix the bugs, but obsessing about pointless checks for one particular type of potential bugs is no help to anyone. It's just an excuse for not thinking and not paying attention to what you are doing. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment