Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #107805 > unrolled thread

How to fix: [-Wformat-nonliteral]

Back to article view | Back to comp.lang.c

Contents

  How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-07 12:20 +0430
    Re: How to fix: [-Wformat-nonliteral] Barry Schwarz <schwarzb@dqel.com> - 2017-04-07 01:28 -0700
    Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 11:58 +0200
      Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-07 11:43 +0100
        Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 13:35 +0200
      Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-07 13:50 +0100
        Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 15:54 +0200
          Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-07 19:35 +0100
            Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-08 13:41 +0200
              Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-10 13:52 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-11 00:18 +0200
                  Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-10 15:43 -0700
                    Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-10 16:10 -0700
                      Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-10 16:26 -0700
                    Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-11 11:33 +0200
                      Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-11 08:37 -0700
                        Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-13 00:20 +0200
                          Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-12 15:55 -0700
                            Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-12 18:17 -0700
                            Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-14 12:27 +0200
                              Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-14 11:57 -0700
                                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-17 18:08 +0200
                                  Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-17 09:38 -0700
                          Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-12 18:13 -0700
                            Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 07:37 -0700
                              Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-13 08:43 -0700
                                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 11:24 -0700
                                  Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-13 11:49 -0700
                                    Re: How to fix: [-Wformat-nonliteral] Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 14:43 -0500
                                      Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 13:26 -0700
                                      Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-13 13:32 -0700
                                        Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 14:27 -0700
                                          Re: How to fix: [-Wformat-nonliteral] Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 17:39 -0500
                                            Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 16:16 -0700
                                      Re: How to fix: [-Wformat-nonliteral] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 17:53 -0700
                                    Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 13:19 -0700
                                    Re: How to fix: [-Wformat-nonliteral] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 17:49 -0700
                                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-17 18:14 +0200
                                  Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-17 11:54 -0700
                                    Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-17 22:41 +0200
                                      Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-17 15:02 -0700
                            Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-14 12:40 +0200
                              Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-14 12:10 -0700
                                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-14 13:22 -0700
                                  Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-14 17:14 -0700
                        Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-13 00:20 +0200
        Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-07 20:29 +0430
          Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 18:42 +0200
            Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-08 08:04 +0430
              Re: How to fix: [-Wformat-nonliteral] Richard Heathfield <rjh@cpax.org.uk> - 2017-04-08 07:51 +0100
                Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-08 12:11 +0430
                  Re: How to fix: [-Wformat-nonliteral] Richard Heathfield <rjh@cpax.org.uk> - 2017-04-08 11:38 +0100
                    Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-08 18:52 +0100
              Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-08 13:48 +0200
                Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-08 20:34 +0430

Page 3 of 3 — ← Prev page 1 2 [3]

#108255

David Brown <david.brown@hesbynett.no> writes:
> On 17/04/17 20:54, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 13/04/17 17:43, Keith Thompson wrote:
>> [...]
>>>> And if you make double 32 bits, what about long double?
>>>
>>> Typically, it is non-existant.  There are a good many embedded
>>> development tools where the support for C99 is limited, and this is a
>>> common limitation.
>>
>> This isn't the first time I've seen the incorrect idea that long double
>> was added in C99.  In fact it existed in C89/C90.  (C99 did add <math.h>
>> functions for float and long double; C90's <math.h> only provided
>> functions for double.)  The ANSI C Rationale mentions "long double" as a
>> new type.
>
> Really?  That is news to me - but then, I come here to learn!
>
> The only compilers I have used that have supported long double have been 
> those with good C99 support (like gcc, Code Warrior, Green Hills, and a 
> few others) - while those with little or no C99 support invariably have 
> no long doubles either.

Type long double has exactly the same minimum requirements as double, so
any compiler that *correctly* supports double can support long double
without much extra effort.  But for a non-conforming compiler that
provides a narrower representation for double, supporting long double
would not add much value.

>> Still, dropping long double for a *non-conforming* compiler for a small
>> embedded system is likely to be a good idea.
>
> Indeed.  For most tools for small microcontrollers, that sort of 
> non-conformity is to be expected.  And no one (or very few people) are 
> going to miss long double support on their 8 bit microcontrollers.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#108121

On 13/04/17 03:13, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/04/17 17:37, supercat@casperkitty.com wrote:
>>> On Tuesday, April 11, 2017 at 4:33:26 AM UTC-5, David Brown wrote:
<snip>
>
> Note that for an implementation that documents that it supports `void
> main(void)`, all the requirements in the standard (aside from the
> termination status) are in full force.  Omitting zero-initialization of
> static objects would still make the implementation non-conforming.
>
> I suppose a implementation could (a) *not* document `void main(void)`
> as "some other implementation-defined manner" under 5.1.2.2.1, but
> (b) document `void main(void)` as an extension under 4p6, and then
> do anything it likes.  But that would be perverse.
>
> An implementation can certainly support an extension that
> doesn't zero-initialize static objects, as long as that extension
> doesn't break any strictly conforming program.  For example, a
> compiler-specific #pragma would be OK.  Triggering the behavior
> based on the return type of main would IMHO be silly.
>

A common way to have data that is not zero initialised is to specify 
that it be placed in a specific data section (rather than the common 
standard .bss).  It is nice, clear, and doesn't break anything.  That's 
the way I like to see it done.

> (Note that `main` is relevant only for hosted implementations.)
>
> [...]
>
>> I agree that for some targets, it can be better to make some breakage to
>> C standards conformity.  But that should be kept to the absolute
>> minimum, be well documented, not break working code silently, and
>> preferably require a command-line switch to activate it or give warnings
>> about the odd behaviour.  It is reasonable, for example, for a C
>> implementation on a small 8-bit micro to make "double" limited to 32
>> bits.  It is /not/ reasonable to change the meaning of a keyword like
>> "const" to mean something subtly different, or to skip the zeroing of
>> uninitialised data.
>
> Wouldn't it be better to support 32-bit "float" and reject "double"?
> It's non-conforming either way, but it would cleanly reject code that
> uses "double" and quite reasonably expects it to be wider than 32
> bits.
>

That would certainly have its advantages.  However, it is very common to 
use doubles in code without really thinking about it:

	float x, y, z;
	z = 2.0 * x + y;

The 2.0 is a double - to keep everything in floats, it would need to be 
2.0f.  Making doubles the same as floats keeps the source code simple.

The ideal solution, I think can be the way gcc handles it for devices 
like the ARM Cortex M4F - a 32-bit microcontroller with hardware support 
for single precision floating point but not double precision.  Without 
options, it works as standard C - doubles are 64-bit.  You can have a 
switch for warnings if your code uses doubles, and you can use a switch 
to make literals such as 2.0 act as single-precision.  You have all the 
options and controls you might want, but by default everything is standard.

[toc] | [prev] | [next] | [standalone]

#108148

On Friday, April 14, 2017 at 5:40:41 AM UTC-5, David Brown wrote:
> That would certainly have its advantages.  However, it is very common to 
> use doubles in code without really thinking about it:
> 
> 	float x, y, z;
> 	z = 2.0 * x + y;
> 
> The 2.0 is a double - to keep everything in floats, it would need to be 
> 2.0f.  Making doubles the same as floats keeps the source code simple.

If the rules for "long double" had said that they are passed the same as
"double" except when either a prototype exists that specifies "long double"
or the argument expression *is* an explicit cast to long double, then all
constants could have supplied long double values at the compiler's leisure,
perhaps with a language rule that would indicate that given expressions
like:

    float f = someFloat * 0.1;
    double d = someDouble * 0.1;

a compiler would be allowed to perform the multiplication using whichever
type was most convenient and a constant suitable for that type (if there
were such a rule, there should be a suffix to explicitly indicate double
literals, in case one wanted to force the use of extra precision).  

> The ideal solution, I think can be the way gcc handles it for devices 
> like the ARM Cortex M4F - a 32-bit microcontroller with hardware support 
> for single precision floating point but not double precision.  Without 
> options, it works as standard C - doubles are 64-bit.  You can have a 
> switch for warnings if your code uses doubles, and you can use a switch 
> to make literals such as 2.0 act as single-precision.  You have all the 
> options and controls you might want, but by default everything is standard.

What about variadic functions?

[toc] | [prev] | [next] | [standalone]

#108151

supercat@casperkitty.com writes:
> On Friday, April 14, 2017 at 5:40:41 AM UTC-5, David Brown wrote:
>> That would certainly have its advantages.  However, it is very common to 
>> use doubles in code without really thinking about it:
>> 
>> 	float x, y, z;
>> 	z = 2.0 * x + y;
>> 
>> The 2.0 is a double - to keep everything in floats, it would need to be 
>> 2.0f.  Making doubles the same as floats keeps the source code simple.
>
> If the rules for "long double" had said that they are passed the same as
> "double" except when either a prototype exists that specifies "long double"
> or the argument expression *is* an explicit cast to long double, then all
> constants could have supplied long double values at the compiler's leisure,
> perhaps with a language rule that would indicate that given expressions
> like:
>
>     float f = someFloat * 0.1;
>     double d = someDouble * 0.1;
>
> a compiler would be allowed to perform the multiplication using whichever
> type was most convenient and a constant suitable for that type (if there
> were such a rule, there should be a suffix to explicitly indicate double
> literals, in case one wanted to force the use of extra precision).  

So you propose that given
    long double x;
these calls:
    func(x)
    func((long double)x)
should have different semantics.

I hate that idea.  I'm not sure what you're trying to achieve, but I
suggest finding a different way to do it.

[...]

The idea, I think, is to provide a *non-conforming* C implementation for
a target that supports 32-bit floating-point but nothing wider (assuming
software floating-point is impractical or not worthwhile).  Given the
central role played by type double, I'm thinking a good approach would
be to make float and double both 32 bits while keeping all the other
language rules in place.  Type long double could either be dropped or
made 32 bits.  I suggest dropping it, since code that uses long double
probably depends on extra precision and/or range.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#108154

On Friday, April 14, 2017 at 3:22:50 PM UTC-5, Keith Thompson wrote:
> So you propose that given
>     long double x;
> these calls:
>     func(x)
>     func((long double)x)
> should have different semantics.

There would be no reason to invoke a single-argument function without a
prototype in scope.  Having a rule that says that all floating-point
arguments are passed as the same type, period, would be the logical way
to handle things save for one problem: if existing code on a system
expects that floating-point values will be passed as 64 bits, but there
is a need to pass a more precise floating-point number to something like
printf, there needs to be some syntax for saying "Pass this particular
argument as an extended-precision type rather than converting it to a
64-bit double."  Perhaps it would be better to use some syntax other than
using the existing cast syntax for that purpose, but the key point is that
in all floating-point arguments should be passed in compatible fashion
except when something special is done to explicitly request otherwise.

[toc] | [prev] | [next] | [standalone]

#108084

On 11/04/17 17:37, supercat@casperkitty.com wrote:
> On Tuesday, April 11, 2017 at 4:33:26 AM UTC-5, David Brown wrote:
>> On 11/04/17 00:43, supercat wrote:
>>> On Monday, April 10, 2017 at 5:18:39 PM UTC-5, David Brown wrote:
>>> I don't think the Standard allows compilers to regard as Undefined Behavior
>>> the use of any entry-function signature other than those explicitly described.
>>> If an implementation that didn't describe any behavior for "void main()"
>>> would be allowed to treat it as UB, I see no reason that it shouldn't be
>>> allowed to describe a useful behavior that differs from "int main()".
>>>
>>
>> I can't figure out what you are trying to say here.  We are not talking
>> about undefined behaviour here - we are talking about a non-conforming
>> implementation of the compiler.
>
> If some compiler X doesn't document any particular behavior for "void main()"
> but such code happens to behave like "int main()" but without variable
> initialization, such behavior would be conforming since use of "void main()"
> would be UB, making all possible actions conforming.
>
> If some compiler Y were identical to X except that it *documented* that
> "void main()" would work as it does in compiler X, then "void main()" would
> not be UB on compiler Y, but I see no reason that compiler Y shouldn't be
> conforming.
>
>>> The "const" pointers were treated as a "universal" pointer type that could
>>> access things in either RAM or flash/ROM.
>>
>> C does not make a distinction between RAM or ROM.  /All/ pointers in C
>> to a given type are "universal" pointers.  A const pointer is a pointer
>> which the /programmer/ promises he will not use to modify data.  Data
>> that is defined as const is stronger - there the compiler /knows/ that
>> the data will never be modified, and is allowed to place it in read-only
>> memory.
>
> I'm well aware of that.  The question is whether it's better to have a
> compiler:
>
>   1. default to RAM-only pointers and require that all objects fit in
>      RAM unless they have a special qualifier that makes them only
>      accessible via specially-qualified pointers
>
>   2. default to universal pointers and require that any code that needs
>      to perform well with data in RAM use qualifiers to allow that, or
>      have the default behavior in the absence of vendor-specific
>      qualifiers depend upon whether things are "const" qualified.  If I
>      were designing a compiler, I'd be inclined to allow command line
>      settings or #pragma directives select among such behaviors, since
>      there are situations where each could be most useful, but the
>      non-conforming option is probably the one which would allow the
>      largest amount of code to work efficiently without modification.
>
>> Of course, a compiler implementation can provide extensions beyond this
>> model - and perhaps limitations if necessary in order to keep an
>> efficient implementation.  But a compiler implementation may not usurp
>> normal standard C keywords and usage for such different behaviour.
>
> Compilers can do whatever they want.  Such behavior may make them non-
> conforming, but in some situations a non-conforming compiler might be more
> useful than any fully-conforming compiler ever could be.  For example, on
> an 8-bit processor, a compiler that has a single 32-bit floating-point type
> may be more useful than one which can't pass floating-point values to
> variadic functions without bundling 48-bit-or-larger math code.  If code
> never needs anything beyond standard float precision, the extra machine code
> for larger types would represent a waste of time and space.
>
>> In this particular case, the microcontroller in question was an AVR.
>> This is an 8-bit device, and it uses different cpu instructions to
>> access memory in RAM from memory in Flash.  The old compiler (I omit the
>> name to protect the guilty) was trying to make it convenient for casual
>> users to have data such as tables or strings in flash.  In contrast, the
>> standard compiler for this chip is gcc which uses normal semantics and
>> normal standard C.  This means that if you write "const int x = 1234;"
>> and take the address of x, then x will be placed in RAM - even though it
>> never changes.  This is necessary to make pointers work properly, as
>> normal C.  The compiler provides extensions to allow you to put data
>> specifically in flash and access it directly (including a type of
>> universal pointer that can access anything).
>
> That's certainly a reasonable approach, and a quality compiler should
> probably offer it as an option, but for many purposes a non-conforming
> option that works like other compilers do may be more useful.
>
>>>  A pointer type for things that
>>> were known to be in flash would have improved efficiency in some cases,
>>> though access through flash was generally slow enough that the extra time
>>> to check whether a pointer was a RAM address wasn't a problem.  The treatment
>>> meant that a *const* was incompatible with a **, and meant that code which
>>> needlessly applied "const" to pointers would run much more slowly than it
>>> should, but maintained correct behavior in most cases.
>>>
>>> Maintaining compatibility with 100% of code would require using two-byte
>>> pointers for everything and generating a function call for every pointer
>>> access.  While requiring that code mark everyplace where a one-byte pointer
>>> should be used might have worked, it would have required a lot of code
>>> markup.
>>>
>>>>>> Integer promotion rules aimed at being "helpful" to the programmer,
>>>>>> rather than following the standards.
>>>>>
>>>>> The Standard allows implementations some flexibility to be helpful with
>>>>> regard to signed integers.  Unsigned integer types have rigidly-defined
>>>>> behavior.
>>>>
>>>> No, it does not allow such flexibility.  If you have a uint8_t or an
>>>> int8_t, and you perform arithmetic, it is to be promoted to "int" before
>>>> carrying out the operation.  A compiler that does not do that
>>>> (logically, at least - it does not actually have to do the 16+ bit
>>>> operations if only parts of the results are used) is a broken compiler
>>>> that causes confusion and means code that should be portable and
>>>> testable on different targets, no longer works.
>>>
>>> A compiler could just as well promote to an even longer type at its
>>> convenience, except in contexts like "sizeof", since operations on the
>>> longer type would behave identically to "int" in all cases where the
>>> Standard would impose any requirements upon the latter....
>
>> You don't need to repeat your favourite bugbear yet again - it is not
>> relevant here, any more than it is most of the times you bring it up.
>
> What about the other point (requoted above): given code like:
>
>     int64_t mul_and_add(int32_t x, int32_t y)
>     {
>       return x*y;
>     }
>
> When generating code for a 32-bit processor that includes a 32x32->64
> multiply instruction, the Standard would allow a compiler to, at its
> leisure, either perform the multiply as 32x32->32 and sign-extend, or
> else perform a 32x32->64 computation and return the result as-is?  I
> don't know of any compilers that would actually promise the latter,
> but the Standard would certainly allow a compiler to do so.  On a
> processor which uses 32-bit "int" on a 64-bit processor, such a promise
> would be rather cheap, though code would have to avoid expressions that
> mixed uint32_t with int32_t or smaller types to avoid icky semantics.
>

[toc] | [prev] | [next] | [standalone]

#107820

On 04/07/2017 05:20 PM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:

[...]

>
> I might even just write
>
> #define my_err(...) \
> 	do { \
> 		char buff[256]; \
> 		snprintf(buff, sizeof(buff), __VA_ARGS__); \
> 		my_err_s(buff); \
> 	} while (0)
>

[...]

Does the above macro write to stderr?


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#107825

On 07/04/17 17:59, MehdiAmini wrote:
> On 04/07/2017 05:20 PM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
> 
> [...]
> 
>>
>> I might even just write
>>
>> #define my_err(...) \
>>     do { \
>>         char buff[256]; \
>>         snprintf(buff, sizeof(buff), __VA_ARGS__); \
>>         my_err_s(buff); \
>>     } while (0)
>>
> 
> [...]
> 
> Does the above macro write to stderr?
> 
> 

The macro does not write anywhere - it calls "my_err_s".  The function
definition I gave for "my_err_s" earlier writes to stderr.

If you are new to C, and we are going too fast for you, then please let
us know.  There are plenty of people in this group that are happy to
help beginners, but unless you say then we must assume you are
reasonably familiar with the language.  But if you /were/ familiar with
the language, you would know the answer to your own question here!

[toc] | [prev] | [next] | [standalone]

#107843

On 04/07/2017 09:12 PM, David Brown wrote:
> On 07/04/17 17:59, MehdiAmini wrote:

[...]

> If you are new to C, and we are going too fast for you, then please let
> us know.  There are plenty of people in this group that are happy to
> help beginners, but unless you say then we must assume you are
> reasonably familiar with the language.  But if you /were/ familiar with
> the language, you would know the answer to your own question here!
>

[...]

Sorry, I am _not_ new to C. I just made a wrong assumption that this 
my_err_s is somehow like printf_s and scanf_s.


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#107851

On 08/04/17 04:34, MehdiAmini wrote:
> On 04/07/2017 09:12 PM, David Brown wrote:
>> On 07/04/17 17:59, MehdiAmini wrote:
>
> [...]
>
>> If you are new to C, and we are going too fast for you, then please let
>> us know.  There are plenty of people in this group that are happy to
>> help beginners, but unless you say then we must assume you are
>> reasonably familiar with the language.  But if you /were/ familiar with
>> the language, you would know the answer to your own question here!
>>
>
> [...]
>
> Sorry, I am _not_ new to C. I just made a wrong assumption that this
> my_err_s is somehow like printf_s and scanf_s.

Why not ask Google instead of wasting your time asking experts? Their 
answers are very unlikely to show up on a Google search, so it's obvious 
they have nothing of value to tell you.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#107853

On 04/08/2017 11:21 AM, Richard Heathfield wrote:
> On 08/04/17 04:34, MehdiAmini wrote:
>> On 04/07/2017 09:12 PM, David Brown wrote:
>>> On 07/04/17 17:59, MehdiAmini wrote:
>>
>> [...]
>>
>>> If you are new to C, and we are going too fast for you, then please let
>>> us know.  There are plenty of people in this group that are happy to
>>> help beginners, but unless you say then we must assume you are
>>> reasonably familiar with the language.  But if you /were/ familiar with
>>> the language, you would know the answer to your own question here!
>>>
>>
>> [...]
>>
>> Sorry, I am _not_ new to C. I just made a wrong assumption that this
>> my_err_s is somehow like printf_s and scanf_s.
>
> Why not ask Google instead of wasting your time asking experts? Their
> answers are very unlikely to show up on a Google search, so it's obvious
> they have nothing of value to tell you.
>

Sorry, you misunderstood me on the "Reliable C tutorial for beginners" 
thread. When I said that your suggested tutorial is not shown up in 
several search engines first page, I meant that beginners who search for 
a tutorial on C, would read a tutorial that may misinform them since 
they may not be reliable tutorials. By the way I actually read your 
suggested tutorial. Even though I am not a beginner in C.


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#107856

On 08/04/17 08:41, MehdiAmini wrote:
<snip>
>
> Sorry, you misunderstood me on the "Reliable C tutorial for beginners"
> thread. When I said that your suggested tutorial is not shown up in
> several search engines first page, I meant that beginners who search for
> a tutorial on C, would read a tutorial that may misinform them since
> they may not be reliable tutorials.

That comment might reasonably have been addressed to the purveyors of 
the Internet search engines that you used, but there's no earthly point 
in raising it here.

> By the way I actually read your
> suggested tutorial. Even though I am not a beginner in C.

Even C experts are likely to learn something from Tom's tutorial.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#107878

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 08/04/17 08:41, MehdiAmini wrote:
> <snip>
>>
>> Sorry, you misunderstood me on the "Reliable C tutorial for beginners"
>> thread. When I said that your suggested tutorial is not shown up in
>> several search engines first page, I meant that beginners who search for
>> a tutorial on C, would read a tutorial that may misinform them since
>> they may not be reliable tutorials.
>
> That comment might reasonably have been addressed to the purveyors of
> the Internet search engines that you used, but there's no earthly
> point in raising it here.

Surely it's helpful for others to know that?  Someone might come across
this thread when searching for C tutorials but might not see the one
that contains the recommended link.  It's not exactly a must post remark
but it seemed to be intended in a helpful way and I thought, on
refection, that it might indeed be helpful.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#107859

On 08/04/17 05:34, MehdiAmini wrote:
> On 04/07/2017 09:12 PM, David Brown wrote:
>> On 07/04/17 17:59, MehdiAmini wrote:
>
> [...]
>
>> If you are new to C, and we are going too fast for you, then please let
>> us know.  There are plenty of people in this group that are happy to
>> help beginners, but unless you say then we must assume you are
>> reasonably familiar with the language.  But if you /were/ familiar with
>> the language, you would know the answer to your own question here!
>>
>
> [...]
>
> Sorry, I am _not_ new to C. I just made a wrong assumption that this
> my_err_s is somehow like printf_s and scanf_s.
>

That's an odd assumption.  /Your/ function was called "my_err", so when 
changing it to a macro I needed an extra function name and used 
"my_err_s".  And I gave an implementation of it my post.

But people make mistakes or misread posts sometimes - no harm done.  Go 
back and read my first answer in this thread, and see if it will do the 
job you need.  (But use Ben's improvements to the macro.)

[toc] | [prev] | [next] | [standalone]

#107873

On 04/08/2017 04:18 PM, David Brown wrote:
> On 08/04/17 05:34, MehdiAmini wrote:
>> On 04/07/2017 09:12 PM, David Brown wrote:
>>> On 07/04/17 17:59, MehdiAmini wrote:

[...]

> But people make mistakes or misread posts sometimes - no harm done.  Go
> back and read my first answer in this thread, and see if it will do the
> job you need.  (But use Ben's improvements to the macro.)
>
>

I am using this method, and it seems to work correctly.

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web