Deutsch   English   Français   Italiano  
<vvv7ki$1onda$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Tue, 13 May 2025 12:41:22 +0200
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <vvv7ki$1onda$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vtf7fe$1qtpg$1@dont-email.me>
 <vtgfuf$31ug1$1@dont-email.me> <20250413072027.219@kylheku.com>
 <vtgpce$39229$1@dont-email.me> <vti2ki$g23v$1@dont-email.me>
 <vtin99$vu24$1@dont-email.me> <vtiuf0$18au8$1@dont-email.me>
 <vtj97r$1i3v3$1@dont-email.me> <vtl166$36p6b$1@dont-email.me>
 <vtlcg0$3f46a$2@dont-email.me> <20250415153419.00004cf7@yahoo.com>
 <86h62078i8.fsf@linuxsc.com> <20250504180833.00000906@yahoo.com>
 <86plggzilx.fsf@linuxsc.com> <vvnsvt$3k1mu$1@dont-email.me>
 <86ldr4yx0x.fsf@linuxsc.com> <vvpmm2$3dhl$1@dont-email.me>
 <vvpsji$4jht$1@dont-email.me> <vvr5mg$l85c$1@dont-email.me>
 <vvt2tg$14otk$2@dont-email.me> <8734d936p5.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 13 May 2025 12:41:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b3a8bbc5a5dd7af994c73820a2a11016";
	logging-data="1858986"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19hjKhMPwfslITOpAVV/fJiRb9R/lPSKX8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:CtXseqHZ9k5FpNPCN3b40lNhDkg=
In-Reply-To: <8734d936p5.fsf@nosuchdomain.example.com>
Content-Language: en-GB

On 12/05/2025 22:38, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I am not convinced that it is actually useful as an error checking
>> mechanism in many situations.  In a lot of code, you simply don't have
>> a compile-time checkable array sizes - you have a pointer, and a
>> run-time variable for the size.  When you are calling your function
>> with a "static" array size, the compiler does not have any way to
>> check your pointer for correctness.
> [...]
> 
> Using [static N] in an array parameter declaration also requires the
> caller to pass a non-NULL pointer.  If I want to tell the compiler
> that an argument must not be a NULL pointer, I can write:
> 
>      void func(int arg[static 1]);
> 
> func(NULL) then has undefined behavior, and a compiler is likely
> to warn about it.  (Of course some UB will be missed if the compiler
> can't detect it.)
> 

Certainly compilers are more likely to be able to differentiate between 
null values and non-null values, than between pointers to different 
lengths of data.  So yes, this can be a useful check.

For my own use, I dislike this syntax - if I want a pointer to an int, I 
prefer to give the parameter the form pointer to an int.  The array form 
might mean the same thing to the compiler, but it does not give the same 
clarity to the human programmer.  And if I want extra checking on this 
kind of thing, I use gcc attributes.  (Of course not all programmers can 
do that, or want to do that, in their code.)