variadic functions
Frank
An example is:
#include <stdio.h>
#include <string.h>
int main() {
char s[10];
strcpy(s,"abcdefg");
strchr(s,'c')[1]='x';
printf("%s\n",s);
printf ("execution was here");
return 0;
}
Can someone say with clarity exactly what happens in the this line:
strchr(s,'c')[1]='x';
I think it's called array subscripting. Can someone post an example
of useful code that uses this feature?
Another thing we don't have are variadic functions. This was
particularly hard to understand from the K&R material, where I came
away from it thinking the ellipses were added by the book as opposed
to a language token.
#include <string.h>
int main(void)
{
int printf(const char *, ...);
char s[10];
strcpy(s,"abcdefg");
strchr(s,'c')[1]='x';
printf("%s\n",s);
printf ("execution was here");
return 0;
}
How is this program different from the first?
Eric Sosman
> I seem to be interested in places where C and fortran are different.
I seem to hope the seeming resembles reality.
> An example is:
> #include <stdio.h>
> #include <string.h>
> int main() {
> char s[10];
> strcpy(s,"abcdefg");
> strchr(s,'c')[1]='x';
> printf("%s\n",s);
> printf ("execution was here");
> return 0;
> }
>
> Can someone say with clarity exactly what happens in the this line:
> strchr(s,'c')[1]='x';
> I think it's called array subscripting. Can someone post an example
> of useful code that uses this feature?
There are two things about C you need to know to make sense
of this.
The first is sometimes called The Rule: In most contexts
(all but two), writing the name of an array in an expression is
the same as writing a pointer to the array's first element.
That's why the strcpy() and strchr() and printf() calls' use of
the array name s is the same as writing &s[0], a pointer to the
zero'th element of the array s.
The second is that the indexing operator [] is *defined*
in terms of arithmetic on pointers: arr[j] means *(arr+j). This
causes giggles among immature schoolchildren when they suddenly
realize that addition is commutative, so *(arr+j) is the same as
*(j+arr), which is the same as j[arr]. Tee hee, snicker.
Since indexing is defined in terms of pointer arithmetic,
you don't need to do it on an actual array: You can do it with
any pointer and any integer (as long as the result is in range).
So arr[j] is legal, but so is p[j] when p is a pointer (or when
p is an integer and j is a pointer, tee hee, snicker). Apply
The Rule: p[j] means *(p+j). This use of the same notation with
both arrays and pointers is sometimes referred to as "equivalence
of pointers and arrays," which is slightly misleading because
they are not entirely equivalent. (Examine the values of
sizeof(s) and sizeof(&s[0]) to see one inequivalence.)
Okay, now you've got what you need to understand the line
that puzzles you. strchr() returns a pointer to char, a char*.
By The Rule, strchr(s,'c')[1] means *(strchr(s,'c')+1). As long
as strchr() doesn't return NULL (which it doesn't in your case),
the addition inside the parentheses is valid (it is *not* valid
to add or subtract from a NULL-valued pointer). So: strchr(s,'c')
returns a pointer to the 'c' at the [2] position in s, adding 1
produces a pointer to one place further along -- to the [3] spot
in s, where the 'd' resides, and then you store 'x' in that spot.
> Another thing we don't have are variadic functions. This was
> particularly hard to understand from the K&R material, where I came
> away from it thinking the ellipses were added by the book as opposed
> to a language token.
>
> #include <string.h>
> int main(void)
> {
> int printf(const char *, ...);
> char s[10];
> strcpy(s,"abcdefg");
> strchr(s,'c')[1]='x';
> printf("%s\n",s);
> printf ("execution was here");
> return 0;
> }
> How is this program different from the first?
It's sillier. The free-hand declaration of printf() is
correct and legal (in C99 it is not quite perfect, but still
legal as far as I know), but dumb. Many functions from the
Standard library *can* be declared free-hand, but it's silly
to do so. Some can be so declared and the program will work,
but you may find that it runs slower than if you'd included
the proper header. And there are several library functions
that *cannot* be declared free-hand, without their headers.
By the way, both programs exhibit implementation-defined
behavior: The "execution was here" line might or might not
actually show up on the output, or might show up only in part.
Always write a '\n' at the end of a text output stream.
--
Eric Sosman
eso...@ieee-dot-org.invalid
io_x
"Frank" <mer...@lomas-assault.net> ha scritto nel messaggio
news:23c2ebd2-dd31-43b0...@z4g2000prh.googlegroups.com...
>I seem to be interested in places where C and fortran are different.
> An example is:
> #include <stdio.h>
> #include <string.h>
> int main() {
> char s[10];
> strcpy(s,"abcdefg");
> strchr(s,'c')[1]='x';
like someother says
"strchr(s,'c')[1]='x';"
"*(strchr(s,'c')+1)='x';"
would be the same
> printf("%s\n",s);
> printf ("execution was here");
> return 0;
> }
>
> Can someone say with clarity exactly what happens in the this line:
> strchr(s,'c')[1]='x';
> I think it's called array subscripting. Can someone post an example
> of useful code that uses this feature?
>
> Another thing we don't have are variadic functions. This was
> particularly hard to understand from the K&R material, where I came
> away from it thinking the ellipses were added by the book as opposed
> to a language token.
>
> #include <string.h>
> int main(void)
> {
> int printf(const char *, ...);
in what i know here you say to the linker to find
"int printf(const char *, ...);"
that could be different from printf in <stdio.h>?
in a function
int f(int a, ...);
means that i can call f with at last one argument f(1)
but they can be 2 f(2,1), 3 f(1,2,3) 4 f(1,2,3,4) etc
the sys when program runs do all necessary
(push pop clear the stack etc)
Paul N
> "Frank" <merr...@lomas-assault.net> ha scritto nel messaggionews:23c2ebd2-dd31-43b0...@z4g2000prh.googlegroups.com...
> > #include <string.h>
> > int main(void)
> > {
> > int printf(const char *, ...);
>
> in what i know here you say to the linker to find
> "int printf(const char *, ...);"
> that could be different from printf in <stdio.h>?
I think you (io_x) could be making the same mistake here that I did
when I first learnt C. I thought that printf was "in" stdio.h, ie that
stdio.h contained the code to do printing. This is not the case.
Headers, such as stdio.h, contain text. This text can be included into
your program, and will have the same effect as if you included that
same text yourself in your program file. In the case of printf,
stdio.h contains a prototype, so that your program knows how to call
printf properly, but it doesn't have a clue what printf actually does.
Somewhere else, for example in a file called something.lib, there is
the actual machine code for printf, and when you link the program the
linker will find this and do the right thing with it, which will
normally involve copying the code into your executable.
My first compiler had six different .LIB files, but this wasn't so
that each only covered some of the functions, the way that .h files
do. They were because the computer had a choice of six different
"memory models" which each required slightly different versions of the
functions. Each .LIB file contained all of the functions.
Hope that helps.
Paul.
Frank
> Frank wrote:
> > I seem to be interested in places where C and fortran are different.
>
> I seem to hope the seeming resembles reality.
OT reminds of Poe:
And I hold within my hand
Grains of the golden sand-
How few! yet how they creep
Through my fingers to the deep,
While I weep- while I weep!
O God! can I not grasp
Them with a tighter clasp?
O God! can I not save
One from the pitiless wave?
Is all that we see or seem
But a dream within a dream?
Ok. Thanks for your response, Eric. I struggle with this every time
I take up C again (but less and less). It really me understand to
have someone "talk through" an idiom.
> > Another thing we don't have are variadic functions. This was
> > particularly hard to understand from the K&R material, where I came
> > away from it thinking the ellipses were added by the book as opposed
> > to a language token.
>
> > #include <string.h>
> > int main(void)
> > {
> > int printf(const char *, ...);
> > char s[10];
> > strcpy(s,"abcdefg");
> > strchr(s,'c')[1]='x';
> > printf("%s\n",s);
> > printf ("execution was here");
> > return 0;
> > }
> > How is this program different from the first?
>
> It's sillier. The free-hand declaration of printf() is
> correct and legal (in C99 it is not quite perfect, but still
> legal as far as I know), but dumb. Many functions from the
> Standard library *can* be declared free-hand, but it's silly
> to do so. Some can be so declared and the program will work,
> but you may find that it runs slower than if you'd included
> the proper header. And there are several library functions
> that *cannot* be declared free-hand, without their headers.
Which ones?
>
> By the way, both programs exhibit implementation-defined
> behavior: The "execution was here" line might or might not
> actually show up on the output, or might show up only in part.
> Always write a '\n' at the end of a text output stream.
Right. These prototypes are also very implementation-specific, so in
general, you'd want the the prototype that the vendor thinks you
need. Is everything here kosher:
#include <string.h>
#include <stdlib.h>
int printf(const char *, ...);
void print_it(char *);
int main(void)
{
char * p;
p = malloc(100);
strcpy(p, "ABQ Balloon Fest today");
print_it( p );
free(p);
return 0;
}
Frank
It helps me, Paul :) I think what you're getting at here is how the
machine executes a library function and that what you're saying is
that stdio.h is long gone by this point and that the linker knew where
to find the correctly-prototyped function and paste in the code.
I think io_x was getting at this case:
#include <string.h>
#include <stdlib.h>
int printf(const char *, ...);
int main(void)
{
char * p;
p = malloc(100);
strcpy(p, "ABQ Balloon Fest today");
printf( p );
free(p);
return 0;
}
int printf(char * r, ...)
{
printf ("in function\n");
printf("%s\n", r);
}
I don't know what happens here during compilation or execution.
Frank
> I don't know what happens here during compilation or execution.
I meant with stdio.h included. It draws errors from my
implementation:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int printf(const char *, ...);
int main(void)
{
char * p;
p = malloc(100);
strcpy(p, "ABQ Balloon Fest today");
printf( p );
free(p);
return 0;
}
int printf(char * r, ...)
{
printf ("in function\n");
printf("%s\n", r);
}
Wedit output window build: Sat Oct 03 11:56:39 2009
Error c:\lcc\source\nick2.c: 23 redefinition of 'printf'
Error c:\lcc\source\nick2.c: 5 Previous definition of 'printf' here
Warning c:\lcc\source\nick2.c: 27 missing return value
Compilation + link time:0.0 sec, Return code: 1
Eric Sosman
> On Oct 2, 8:15 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> that *cannot* be declared free-hand, without their headers.
>
> Which ones?
This would be a good time for you to review the Standard
library. It's grown a good deal with C99, but even in the C90
version you should be able to find several examples. Why don't
you just start trying to write free-hand declarations for all
the library functions you can think of, no headers allowed, and
see how far you get before running into a snag?
> Right. These prototypes are also very implementation-specific, so in
> general, you'd want the the prototype that the vendor thinks you
> need.
No, the prototypes are as dictated by the Standard, and
cannot be implementation-specific (aside from trivial matters
like names of function parameters, harmless typedef aliases,
and so on). There may be implementation-specific "magic"
accompanying the prototypes, living elsewhere in the declarations
or in accompanying macros and such. But the prototypes themselves
are inviolate.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Frank
> Frank wrote:
> > On Oct 2, 8:15 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> >> [...] And there are several library functions
> >> that *cannot* be declared free-hand, without their headers.
>
> > Which ones?
>
> This would be a good time for you to review the Standard
> library. It's grown a good deal with C99, but even in the C90
> version you should be able to find several examples. Why don't
> you just start trying to write free-hand declarations for all
> the library functions you can think of, no headers allowed, and
> see how far you get before running into a snag?
That might be a good way to test whether you *really* know these
functions. I can say with confidence that I do not. The only
reference to the Standard Library in Unleashed is the book of the same
name by PJ Plauger. Any opinions on this book?
>
> > Right. These prototypes are also very implementation-specific, so in
> > general, you'd want the the prototype that the vendor thinks you
> > need.
>
> No, the prototypes are as dictated by the Standard, and
> cannot be implementation-specific (aside from trivial matters
> like names of function parameters, harmless typedef aliases,
> and so on). There may be implementation-specific "magic"
> accompanying the prototypes, living elsewhere in the declarations
> or in accompanying macros and such. But the prototypes themselves
> are inviolate.
Hmm. I guess the sentiment arose from difference between
implementations in stdio.h that were #defined.
int printf(const char * restrict format, ...);
p. 430, 1256.pdf
is the Standard way that this is defined. You claim that this is
essentially
int printf(const char *, ...);
Right?
Eric Sosman
> On Oct 3, 12:32 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> Frank wrote:
>>> On Oct 2, 8:15 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>>>> [...] And there are several library functions
>>>> that *cannot* be declared free-hand, without their headers.
>>> Which ones?
>> This would be a good time for you to review the Standard
>> library. It's grown a good deal with C99, but even in the C90
>> version you should be able to find several examples. Why don't
>> you just start trying to write free-hand declarations for all
>> the library functions you can think of, no headers allowed, and
>> see how far you get before running into a snag?
>
> That might be a good way to test whether you *really* know these
> functions. I can say with confidence that I do not.
I'd say I "know" about fifty percent of the Standard
library, taking "know" to mean "I never consult a reference
any more." I "sort of know" another twenty-five percent,
meaning that I can use the functions most of the time but
need to crack open a book for corner cases. And there's
another twenty-five percent that I just plain don't use and
can't claim familiarity with: Most of the new floating-point
and complex-variable functions of C99, the wide-character
functions, and the locale functions come to mind as stuff
my work simply doesn't involve. Even so, I know they exist
and would know that cracking a book would make them available
to me should the need ever arise. (Oh, and bsearch(): I find
it harder to remember how to call bsearch() than just to write
the search in open code.)
> The only
> reference to the Standard Library in Unleashed is the book of the same
> name by PJ Plauger. Any opinions on this book?
If by "this book" you mean PJ Plauger's "The Standard C
Library," I think it excellent. C90-centered, but as I said
above most of the C99 additions are foreign to me anyhow.
If by "this book" you mean "C Unleashed" by a cast of
thousands, I haven't read it and have no opinion.
> Hmm. I guess the sentiment arose from difference between
> implementations in stdio.h that were #defined.
I don't know what you mean by this.
> int printf(const char * restrict format, ...);
> p. 430, 1256.pdf
> is the Standard way that this is defined. You claim that this is
> essentially
> int printf(const char *, ...);
> Right?
No, they're different. One names the fixed parameter and
has the `restrict' qualifier; the other doesn't. I claim that
the presence of the name makes no difference at all, barring
things like pre-existing macro definitions named `format'. As
to whether it's legal to omit the `restrict', I *believe* it is
but it's more a matter of faith than of reason.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Antoninus Twink
> If by "this book" you mean "C Unleashed" by a cast of
> thousands, I haven't read it and have no opinion.
Very delicately put, Eric.
If you and Frank are interested, I'd advise reading some of the threads
started by Han from China earlier this year, pointing out some of the
basic errors in the chapters by Richard Heath Field.
Frank
What version does it have to be? I can pay between 7 and 54 dollars
for this on Amazon. I don't want anything that is tragically
outdated.
> > Hmm. I guess the sentiment arose from difference between
> > implementations in stdio.h that were #defined.
>
> I don't know what you mean by this.
The #defines are more implementation specific than the function
prototypes, by necessity.
>
> > int printf(const char * restrict format, ...);
> > p. 430, 1256.pdf
> > is the Standard way that this is defined. You claim that this is
> > essentially
> > int printf(const char *, ...);
> > Right?
>
> No, they're different. One names the fixed parameter and
> has the `restrict' qualifier; the other doesn't. I claim that
> the presence of the name makes no difference at all, barring
> things like pre-existing macro definitions named `format'. As
> to whether it's legal to omit the `restrict', I *believe* it is
> but it's more a matter of faith than of reason.
I wish I knew how to bet on faith versus reason. Apparently, none of
the functions you referred to in your top-snipped post are in
stdlib.h:
#ifndef __stdlib_h__
#define __stdlib_h__
#include <stddef.h>
#include <_syslist.h>
#define MB_CUR_MAX 2
#define _MAX_PATH 260
#define _MAX_FNAME 256
#define _MAX_EXT 256
#define _MAX_DRIVE 3
#define _MAX_DIR 256
#undef RAND_MAX
#define RAND_MAX 0x7FFF
typedef struct {
int quot; /* quotient */
int rem; /* remainder */
} div_t;
typedef struct {
long quot; /* quotient */
long rem; /* remainder */
} ldiv_t;
typedef struct {
long long quot;
long long rem;
} lldiv_t;
#undef NULL
#define NULL ((void *)0)
#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#define _WCHAR_T_DEFINED
#endif
#ifndef EXIT_FAILURE
#define EXIT_FAILURE 1
#define EXIT_SUCCESS 0
#endif
void abort(void);
int abs(int);
long long llabs(long long);
int atexit(void (*_func)(void));
double atof(const char *);
int atoi(const char *);
char *itoa(int,char *,int);
char *ltoa(long,char *,int);
void * bsearch(const void * _key,const void * _base, size_t _nmemb,
size_t _size,
int (*_compar)(const void *,const void *));
void * calloc(size_t _nmemb, size_t _size);
#if __LCCOPTIMLEVEL > 0
inline div_t __declspec(naked) div(int a,int b)
{
_asm("\tmovl\t(%esp),%eax");
_asm("\tmovl\t4(%esp),%ecx");
_asm("\tcdq");
_asm("\tidivl\t%ecx");
}
#else
div_t div(int _numer, int _denom);
#endif
void exit(int _status);
void _exit(int status);
#define _Exit _exit
void free(void *);
double strtod(const char *restrict nptr,char ** restrict endptr);
long double strtold(const char *restrict nptr,char ** restrict
endptr);
float strtof(const char *restrict nptr,char ** restrict endptr);
char * getenv(const char *_string);
long labs(long);
ldiv_t ldiv(long _numer, long _denom);
lldiv_t lldiv(long long numer,long long denom);
void * malloc(size_t _size);
void qsort(void * _base, size_t _nmemb, size_t _size, int(*_compar)
(const void *, const void *));
int rand(void);
void * realloc(void * _r, size_t _size);
void srand(unsigned _seed);
double strtod(const char *_n, char **_endvoid);
long double strtold(const char *,char **);
long long strtoll(const char *,char **,int);
unsigned long long strtoull(const char *,char **,int);
long strtol(const char *_n, char **_endvoid, int _base);
unsigned long strtoul(const char *_n, char **_end, int _base);
int system(const char *_string);
int putenv(const char *_string);
char * _gcvt(double,int,char *);
char * _fcvt(double,int,int *,int *);
char * ecvt(double,int,int *,int *);
int mbstowcs(wchar_t *,char *,size_t);
size_t wcstombs( char *mbstr, const wchar_t *wcstr, size_t count );
int mblen(char *,size_t);
int mbstrlen(char *s);
long atol(char *_nptr);
#ifndef __ANSIC__ONLY__
#include "safelib.h"
typedef void (*constraint_handler_t)( const char * restrict msg, void
* restrict ptr, errno_t error);
double frand(void);
constraint_handler_t set_constraint_handler_s( constraint_handler_t
handler);
constraint_handler_t get_constraint_handler_s( void );
void abort_handler_s( const char * restrict msg, void * restrict ptr,
errno_t error);
void ignore_handler_s( const char * restrict msg, void * restrict ptr,
errno_t error);
errno_t getenv_s(size_t * restrict len, char * restrict value, rsize_t
maxsize, const char * restrict name);
void *bsearch_s(const void *key, const void *base, rsize_t nmemb,
rsize_t size, int (*compar)(const void *k, const void *y, void
*context), void *context);
errno_t qsort_s(void *base, rsize_t nmemb, rsize_t size, int (*compar)
(const void *x, const void *y, void *context), void *context);
errno_t wctomb_s(int * restrict status, char * restrict s, rsize_t
smax, wchar_t wc);
errno_t mbstowcs_s(size_t * restrict retval, wchar_t * restrict dst,
rsize_t dstmax, const char * restrict src, rsize_t len);
errno_t wcstombs_s(size_t * restrict retval, char * restrict dst,
rsize_t dstmax, const wchar_t * restrict src, rsize_t len);
#ifndef max
#define max(a,b) (((a) > (b)) ? (a) : (b))
#define min(a,b) (((a) < (b)) ? (a) : (b))
#endif
double wtof(const wchar_t *);
char *_fullpath( char *absPath, const char *relPath, size_t
maxLength );
void _makepath(char *path, const char *drive, const char *dir, const
char *fname, const char *ext );
void _splitpath(const char*, char*, char*, char*, char*);
#define _OUT_TO_DEFAULT 0
#define _OUT_TO_STDERR 1
#define _OUT_TO_MSGBOX 2
#define _REPORT_ERRMODE 3
extern int _sleep(unsigned long);
#define sleep _sleep
#define _mbstrlen mbstrlen
#define CRTAPI1
#define _fmode *(_imp___fmode_dll)
extern int _fmode;
extern char ***_imp___environ_dll;
#define _environ (*_imp___environ_dll)
extern unsigned int _osver;
extern unsigned int *(_imp___osver);
#define _osver *(_imp___osver)
extern unsigned int _winmajor;
extern unsigned int *(_imp___winmajor);
#define _winmajor *(_imp___winmajor)
extern unsigned int _winminor;
extern unsigned int *(_imp___winminor);
#define _winminor *(_imp___winminor)
extern unsigned int _winver;
extern unsigned int *(_imp___winver);
#define _winver *(_imp___winver)
void _searchenv(char *,char *,char *);
wchar_t * _itow (int, wchar_t *, int);
wchar_t * _ltow (long, wchar_t *, int);
unsigned short * _ultow (unsigned long, unsigned short *, int);
double wcstod(const wchar_t *, wchar_t **);
long wcstol(const wchar_t *, wchar_t **, int);
int wctomb(char *s,wchar_t wchar);
unsigned long wcstoul(const wchar_t *, wchar_t **, int);
wchar_t * _wgetenv(const wchar_t *);
int _wsystem(const wchar_t *);
int _wtoi(const wchar_t *);
long _wtol(const wchar_t *);
// Contains argv[0]
extern char * __declspec(dllimport) _pgmptr;
int _stdcall _lrotl(unsigned long,unsigned int);
int _stdcall _lrotr(unsigned int,unsigned int);
char *_i64toa(long long,char *,int);
char *_ui64toa(unsigned long long,char *,int);
long long _atoi64(const char *);
#define atoi64 _atoi64
char *_ultoa(unsigned long,char *,int);
unsigned short *_ultow(unsigned long,unsigned short *,int);
#define ultoa _ultoa
#define ultow _ultow
int _stdcall _System(const char *cmd,int nCmdShow);
#endif
#endif /* _STDLIB_H_ */
#include <stdio.h>
#include <string.h>
void Usage(char *programName)
{
fprintf(stderr,"%s usage:\n",programName);
/* Modify here to add your usage message when the program is
* called without arguments */
}
/* returns the index of the first argument that is not an option; i.e.
does not start with a dash or a slash
*/
int HandleOptions(int argc,char *argv[])
{
int i,firstnonoption=0;
for (i=1; i< argc;i++) {
if (argv[i][0] == '/' || argv[i][0] == '-') {
switch (argv[i][1]) {
/* An argument -? means help is requested */
case '?':
Usage(argv[0]);
break;
case 'h':
case 'H':
if (!stricmp(argv[i]+1,"help")) {
Usage(argv[0]);
break;
}
/* If the option -h means anything else
* in your application add code here
* Note: this falls through to the default
* to print an "unknow option" message
*/
/* add your option switches here */
default:
fprintf(stderr,"unknown option %s\n",argv[i]);
break;
}
}
else {
firstnonoption = i;
break;
}
}
return firstnonoption;
}
int main(int argc,char *argv[])
{
if (argc == 1) {
/* If no arguments we call the Usage routine and exit */
Usage(argv[0]);
return 1;
}
/* handle the program options */
HandleOptions(argc,argv);
/* The code of your application goes here */
return 0;
}
This compiles on lcc.
Frank
> On 4 Oct 2009 at 1:43, Eric Sosman wrote:
>
> > If by "this book" you mean "C Unleashed" by a cast of
> > thousands, I haven't read it and have no opinion.
>
> Very delicately put, Eric.
I won't have you bagging on Unleashed on my threads. It is certainly
a dubious achievement to have set a record on errata.
>
> If you and Frank are interested, I'd advise reading some of the threads
> started by Han from China earlier this year, pointing out some of the
> basic errors in the chapters by Richard Heath Field.
What if help if he called himself "Ludwid van der Heide?" What
happened to Han?
Nick Keighley
> On Oct 4, 3:03 am, Antoninus Twink <nos...@nospam.invalid> wrote:
> > On 4 Oct 2009 at 1:43, Eric Sosman wrote:
> > > If by "this book" you mean "C Unleashed" by a cast of
> > > thousands, I haven't read it and have no opinion.
>
> > Very delicately put, Eric.
>
> I won't have you bagging on Unleashed on my threads.
what does "bagging" mean?
In what way is it your thread?
> It is certainly
> a dubious achievement to have set a record on errata.
Is its errata particulary large? Perhaps this reflects some
diligence on behalf of the errata producer. One way to avoid
a large errata is simply not to publish one...
> > If you and Frank are interested, I'd advise reading some of the threads
> > started by Han from China earlier this year, pointing out some of the
> > basic errors in the chapters by Richard Heath Field.
I advise you also read some less biased review before making your mind
up.
Try Amazon and ACCU
> What if help if he called himself "Ludwid van der Heide?" What
> happened to Han?
? what?
Nick Keighley
> > > > If by "this book" you mean "C Unleashed" by a cast of
> > > > thousands, I haven't read it and have no opinion.
It appears to be an e-book
http://www.ebooks.com/ebooks/book_display.asp?IID=334655
Richard
Interesting description:
,----
| Covers the New Standard for C, known as C9X, and includes embedded
| systems, simulation processing, threading and multiprocessing, digital
| signal processing, and natural language processing.
`----
40 dollars for an e-book? Rip off.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Eric Sosman
> On Oct 4, 3:03 am, Antoninus Twink <nos...@nospam.invalid> wrote:
>> On 4 Oct 2009 at 1:43, Eric Sosman wrote:
>>
>>> If by "this book" you mean "C Unleashed" by a cast of
>>> thousands, I haven't read it and have no opinion.
>> Very delicately put, Eric.
As I don't read "Twink," I didn't see this attempt to
twist my words until Frank quoted it. Lest any doubt arise
from "Twink's" attempt to count my vote in his column, I have
not cast a vote at all. "No opinion" means *no* opinion,
positive, negative, or neutral.
I do, however, have an opinion about "Twink."
--
Eric Sosman
eso...@ieee-dot-org.invalid
Eric Sosman
> On Oct 3, 6:43 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>>
>> If by "this book" you mean PJ Plauger's "The Standard C
>> Library," I think it excellent. C90-centered, but as I said
>> above most of the C99 additions are foreign to me anyhow.
>
> What version does it have to be? I can pay between 7 and 54 dollars
> for this on Amazon. I don't want anything that is tragically
> outdated.
Aren't you the one who used the definite pronoun "this" to
refer to the book? Rather than "a" book or "some book or other?"
If you didn't have a particular book in mind, you shouldn't have
used "this."
As for versions, I have no idea what you consider "tragically
outdated." My copy is copyrighted 1992. A lot of people I know
take their daily guidance from a book that has outsold all others
(or has a reasonable claim to have done so) but is much older.
> [... big snip ...]
> This compiles on lcc.
Maybe I'm dense today (it's been a difficult day), but I don't
see the relevance of this gobbet of non-portable code.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Frank
> Frank wrote:
> > On Oct 3, 6:43 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> >> If by "this book" you mean PJ Plauger's "The Standard C
> >> Library," I think it excellent. C90-centered, but as I said
> >> above most of the C99 additions are foreign to me anyhow.
>
> > What version does it have to be? I can pay between 7 and 54 dollars
> > for this on Amazon. I don't want anything that is tragically
> > outdated.
>
> Aren't you the one who used the definite pronoun "this" to
> refer to the book? Rather than "a" book or "some book or other?"
> If you didn't have a particular book in mind, you shouldn't have
> used "this."
>
> As for versions, I have no idea what you consider "tragically
> outdated." My copy is copyrighted 1992. A lot of people I know
> take their daily guidance from a book that has outsold all others
> (or has a reasonable claim to have done so) but is much older.
I seem to know less about libraries than most programmers, so I'll
look forward to getting this. All I saw on Amazon was the 1992
version. I ended up going with one that cost ten bucks and then four
to ship.
I think I share with you a complete indifference to wide character
stuff. It ate a lot of text in H&S V and it all looked the same.
(There might a hint of racism in this sentiment. I'm still recovering
as a bigot.)
> > This compiles on lcc.
>
> Maybe I'm dense today (it's been a difficult day), but I don't
> see the relevance of this gobbet of non-portable code.
I thought you said that there existed functions that are different
than printf() in that you can't duplicate the task of #including the
appropriate header by writing out the defintion yourself. Lcc's
stdlib.h seamed to work just as well pasted in globally as opposed to
#including it.
Nick Keighley
> As for versions, I have no idea what you consider "tragically
> outdated." My copy is copyrighted 1992. A lot of people I know
> take their daily guidance from a book that has outsold all others
> (or has a reasonable claim to have done so) but is much older.
Mao's Little Red Book tell you to program in C?!
"It is well known that when you do anything, unless you understand
its actual circumstances, its nature and its relations to other
things,
you will not know the laws governing it, or know how to do it, or be
able
to do it well."
"Problems of Strategy in China's Revolutionary War" 1936
Nick Keighley
> On Oct 5, 2:57 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > Frank wrote:
> > > On Oct 3, 6:43 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > >> If by "this book" you mean PJ Plauger's "The Standard C
> > >> Library," I think it excellent. C90-centered, but as I said
> > >> above most of the C99 additions are foreign to me anyhow.
>
> > > What version does it have to be? I can pay between 7 and 54 dollars
> > > for this on Amazon. I don't want anything that is tragically
> > > outdated.
<snip>
> I seem to know less about libraries than most programmers, so I'll
> look forward to getting this.
Plauger's book? Excellent book. By the time you've ploughed throgh
that you'll know a lot about the standard C library. For reference
I use Harbison & Steel or just google it.
<snip>
> > > This compiles on lcc.
>
> > Maybe I'm dense today (it's been a difficult day), but I don't
> > see the relevance of this gobbet of non-portable code.
>
> I thought you said that there existed functions that are different
> than printf() in that you can't duplicate the task of #including the
> appropriate header by writing out the defintion yourself.
I haven't a clue what that means. What are "function that are
different
than [sic] printf()"? What does "can't duplicate the task of
#including the
appropriate header by writing out the defintion yourself" mean? For
any
standard library function you can write out the prototype yourself
rather than including the header. This is tedious and error prone
so why would you do that?
> Lcc's
> stdlib.h seamed to work just as well pasted in globally as opposed to
> #including it.
that's what #include does. Why would you do that?
Really. You seem to be hunting for weird ways to do things when the
standard
ways work fine. Perhaps Plauger will help you.
Richard Heathfield
<e6042ac9-18fc-4420...@l34g2000vba.googlegroups.com>,
Nick Keighley wrote:
> On 5 Oct, 22:57, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
>> As for versions, I have no idea what you consider "tragically
>> outdated." My copy is copyrighted 1992. A lot of people I know
>> take their daily guidance from a book that has outsold all others
>> (or has a reasonable claim to have done so) but is much older.
>
> Mao's Little Red Book tell you to program in C?!
I couldn't find any evidence of that, but I did find some useful tips
for Usenet subscribers: "They must be modest and prudent and guard
against arrogance and impetuosity; they must be imbued with the
spirit of selfcriticism and have the courage to correct mistakes and
shortcomings in their work. They must never cover up their errors
like Khrushchov, and claim all the credit for themselves and shift
all the blame on others."
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Eric Sosman
> On Oct 5, 2:57 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> Frank wrote:
>>> This compiles on lcc.
>> Maybe I'm dense today (it's been a difficult day), but I don't
>> see the relevance of this gobbet of non-portable code.
>
> I thought you said that there existed functions that are different
> than printf() in that you can't duplicate the task of #including the
> appropriate header by writing out the defintion yourself. Lcc's
> stdlib.h seamed to work just as well pasted in globally as opposed to
> #including it.
Okay; it was the reference to a "list" of functions that
threw me, because I don't recall seeing a list.
The Standard library contains some functions that cannot
be correctly declared "free-hand," that is, without their
Standard headers. It also contains functions that *can* be
so declared, although it's silly to do so.
The code you showed seemed to be mostly a copy-and-paste
of some implementation's <stdlib.h>, and I guess you consider
that a "free-hand" declaration of the contained functions. For
some -- atof(), for example -- the declaration is just fine and
you could (if in a silly mood) just write that line in your
code and buzz merrily along. But for many, the declaration is
specific to the implementation at hand, and would not work with
others; you'll have written a declaration of Frobozz Magic C's
version of ldiv(), not of Standard C's ldiv().
Well, actually, it's not the declaration of ldiv() itself
that's the problem -- but what about ldiv()'s result? You know
that it returns a struct ldiv_t, but where can you find that
struct type declared? A struct ldiv_t is quite likely arranged
in a way that's convenient to the hardware, and if you moved
your program to different hardware the arrangement would differ.
Claim: The only way to get a struct ldiv_t declaration that
works everywhere is to include <stdlib.h> and let the header
tell you about the local customs.
Then there's rand() -- easy enough to declare portably, but
what will you do if you need the value of RAND_MAX? And it's
easy to write a portable declaration of exit(), and you could
avoid EXIT_SUCCESS by always using zero, but what if you need
the value of EXIT_FAILURE? How will you write a declaration of
malloc(), without knowing what size_t is? (In this case you
could cheat by including one of the other headers that defines
size_t and then writing your malloc() declaration without using
<stdlib.h> itself, but that's a subterfuge.)
There: I've shown you a few <stdlib.h> functions that cannot
be properly declared without <stdlib.h>, and a few that can be
declared but can't be used to their fullest without it. You will
find other similar examples in other Standard headers -- and some
of those functions are not in the least bit esoteric or odd, but
are functions you encounter every day.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Stephen Sprunk
was silently eating all my posts for the last week or so.]
Frank wrote:
> On Oct 3, 10:42 am, Frank <merr...@lomas-assault.net> wrote:
>> I don't know what happens here during compilation or execution.
>
> I meant with stdio.h included. It draws errors from my
> implementation:
>
>
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
> int printf(const char *, ...); /* line 5 */
[snip]
> int printf(char * r, ...) /* line 23 */
[snip]
> Wedit output window build: Sat Oct 03 11:56:39 2009
> Error c:\lcc\source\nick2.c: 23 redefinition of 'printf'
> Error c:\lcc\source\nick2.c: 5 Previous definition of 'printf' here
Your compiler is buggy; line 5 does not define printf() -- it merely
declares it.
However, what I suspect your compiler meant to complain about is that
the argument types of those two lines do not agree; one has a (const
char *) and the other has a (char *).
#include'ing <stdio.h> and then providing your own declaration of
printf() is a Bad Idea(tm). The point of #include'ing headers is so
that you don't _need_ to write those declarations -- which you may get
wrong.
#include'ing <stdio.h> and then providing your own definition of
printf() is also a Bad Idea(tm). If you don't want to use the standard
library's printf() and will provide your own function with that name, do
not #include <stdio.h> -- and expect anyone else who sees your code to
be confused and/or think you're an idiot.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Frank
> [ My apologies for the flood of delayed responses; my old news server
> was silently eating all my posts for the last week or so.]
>
> Frank wrote:
>> On Oct 3, 10:42 am, Frank <merr...@lomas-assault.net> wrote:
>>> I don't know what happens here during compilation or execution.
>>
>> I meant with stdio.h included. It draws errors from my
>> implementation:
>>
>>
>> #include <stdio.h>
>> #include <string.h>
>> #include <stdlib.h>
>> int printf(const char *, ...); /* line 5 */
> [snip]
>> int printf(char * r, ...) /* line 23 */
> [snip]
>> Wedit output window build: Sat Oct 03 11:56:39 2009
>> Error c:\lcc\source\nick2.c: 23 redefinition of 'printf'
>> Error c:\lcc\source\nick2.c: 5 Previous definition of 'printf' here
>
> Your compiler is buggy; line 5 does not define printf() -- it merely
> declares it.
That's not a bug; it's a feature. When I want to say
declaration/definition, I get it wrong more than fifty percent of the time.
My sense was that there was only one definition, and that two different
defintions is not standard C. I'll know more about this when Plauger's
book shows up.
>
> However, what I suspect your compiler meant to complain about is that
> the argument types of those two lines do not agree; one has a (const
> char *) and the other has a (char *).
How about when you throw restrict and format in there?
>
> #include'ing <stdio.h> and then providing your own declaration of
> printf() is a Bad Idea(tm). The point of #include'ing headers is so
> that you don't _need_ to write those declarations -- which you may get
> wrong.
>
> #include'ing <stdio.h> and then providing your own definition of
> printf() is also a Bad Idea(tm). If you don't want to use the standard
> library's printf() and will provide your own function with that name, do
> not #include <stdio.h> -- and expect anyone else who sees your code to
> be confused and/or think you're an idiot.
No one local to me seems to think I'm an idiot.
--
Frank
During the Reagan Administration, Bob Dole was present at a ceremony that
included each living ex-president. Looking at a tableau of Ford, Carter and
Nixon, Dole said, 'There they are: Hear No Evil, See No Evil and Evil.'
~~ Al Franken,
Stephen Sprunk
> In Dread Ink, the Grave Hand of Stephen Sprunk Did Inscribe:
>>> On Oct 3, 10:42 am, Frank <merr...@lomas-assault.net> wrote:
>>>> I don't know what happens here during compilation or execution.
>>>
>>> I meant with stdio.h included. It draws errors from my
>>> implementation:
>>>
>>> #include <stdio.h>
>>> #include <string.h>
>>> #include <stdlib.h>
>>>
>>> int printf(const char *, ...); /* line 5 */
>> [snip]
>>> int printf(char * r, ...) /* line 23 */
>> [snip]
>>> Wedit output window build: Sat Oct 03 11:56:39 2009
>>> Error c:\lcc\source\nick2.c: 23 redefinition of 'printf'
>>> Error c:\lcc\source\nick2.c: 5 Previous definition of 'printf' here
>>
>> Your compiler is buggy; line 5 does not define printf() -- it merely
>> declares it.
>
> That's not a bug; it's a feature.
Humor aside, no. It's a bug.
> When I want to say declaration/definition, I get it wrong more than
> fifty percent of the time.
If you can't get the terms right, that's somewhat understandable; it
took me quite a bit of reading clc before I truly understood the
distinction (especially when you throw the word "prototype" in...).
A compiler author not being able to get the terms right is another
matter; if they can't even get the Standard's terminology right, how can
they possibly produce an implementation that conforms to that Standard?
> My sense was that there was only one definition, and that two different
> defintions is not standard C. I'll know more about this when Plauger's
> book shows up.
Two (or more) definitions of a function, whether the same or different,
are not allowed.
Two (or more) declarations of a function are allowed as long as they all
agree.
A function definition also implicitly declares that function*, which
means that the definition on line 23 must agree with the declaration on
line 5, which in turn must agree with the declaration in <stdio.h>.
(* Probably not the right wording, but IMHO it's close enough for this
discussion.)
>> However, what I suspect your compiler meant to complain about is that
>> the argument types of those two lines do not agree; one has a (const
>> char *) and the other has a (char *).
>
> How about when you throw restrict and format in there?
I'm pretty sure the argument name is irrelevant, but I'm not sure about
a restrict modifier. const-ness definitely matters, at least when it
comes to pointer arguments.
I liken this to operator precedence: if you have to look it up, use
parentheses instead. If you can't remember what parts of a declaration
have to be the same, just make them all the same so you don't have to
worry about it (and neither will anyone else reading your code).
James Kuyper
...
> A function definition also implicitly declares that function*, which
> means that the definition on line 23 must agree with the declaration on
> line 5, which in turn must agree with the declaration in <stdio.h>.
>
> (* Probably not the right wording, but IMHO it's close enough for this
> discussion.)
More precisely, the portion of a function definition that precedes the
function body is, itself, a function declaration.
Antoninus Twink
> --
> Stephen Sprunk "God does not play dice." --Albert Einstein
> CCIE #3723 "God is an inveterate gambler, and He throws the
> K5SSS dice at every possible opportunity." --Stephen Hawking
>
> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="smime.p7s"
> Content-Description: S/MIME Cryptographic Signature
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNjCC
> BTIwggMaoAMCAQICAweCRDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
> HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
> ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA5
> MzAwMDAxNTdaFw0xMDAzMjkwMDAxNTdaMD0xGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEh
> MB8GCSqGSIb3DQEJARYSc3RlcGhlbkBzcHJ1bmsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC
> AQ8AMIIBCgKCAQEA1qAUmWE5Nv/9HFl7f52VrEoGqhbYG1rPE7go13pSxgUBi02iDNKyDTJH
> b/CswpO/FE9p34QbUlnOXY3LRrLh+/NaS496breDA8mRKCceNHIPaiK3Mwpl0q787WQalrp9
> mBV2jKHobOMOWbtNiuYSq6k4qfqIvFJvGOsgizcqeMjjLyR8GimjGCQYuH2o970PhlNidpAj
> mVMCBehc3RhjmevEn4ydIL7j0bmFj9YuLxaoISq6icdh7VFxqAzdEbHhQHKp1N8aNq5yhcWD
> M//Bq8MpMd1+zNse/pVc7/42G5iArYkImUbu/P48PgR8ZX9D59hJxP7kRyKVT9dbTNkh4wID
> AQABo4H+MIH7MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93
> biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQu
> b3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGC
> NwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29j
> c3AuY2FjZXJ0Lm9yZzAdBgNVHREEFjAUgRJzdGVwaGVuQHNwcnVuay5vcmcwDQYJKoZIhvcN
> AQEFBQADggIBAAoGjvt+GUwyjL/hTYUNq9Wvnn9N4pLAUgRNRNwjUOmiVYAr88S3cstdazzK
> DeCaQOsH//LUhU8RzxyPXnxtyl/mDOGDnKuHG2WVEG8hgypfPFV6kNKXBx9FTCKw+B4Mld5f
> kn1iyFQXUAS1exiiFju0YPi+jfQM+bMjY7mFjdAlxYu9spv/FAaedc2sBeuebyuW++mMlIO6
> A3RPjMWPt07qSmcT97aSz9xB1L71K6Ga3EjOI/fszBNfScwaVtXadgp6G8X10ItZOpBWN3y4
> fsJ9is7gAFfIcaKrKK2bv3lH2nFBOYfHKwLk3qvCis825PY5129Yttvap+5sCzvM+ONVmgm/
> l29vOEfGWmgfVkEKyITOizS1QX8ElPsl6+ZH3mDS+/NfRmomQVOidNDz30pGYG7WbqRRTAYJ
> AtcOB0vv4gDTMndB9e+7RsMJQwz3OrL21da6gieSE8NodxVwUWrSAHHKaT/0AxkoVH2pVkqi
> ELw8JOXNV9/b4yNAz14UsNGfmbQQpMO9mVQZWM+Zu1lETHRaNNY5J7Sl/+bsjE+3xavAxV7V
> 4tUTUYIQJVqZgkRB1bZkSJwzWxirdEVj0YHQj1dKOvQl3HBmUVvXw59ALOBqffUAo5qqMdt7
> 2+cwhIs+ZTBNEG7Ulso9g3utPqE+E8sHRRVPi+8WgKByc6V/MYICaTCCAmUCAQEwgYAweTEQ
> MA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYD
> VQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
> QGNhY2VydC5vcmcCAweCRDAJBgUrDgMCGgUAoIG+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
> BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTAwNzE2MTEyOFowIwYJKoZIhvcNAQkEMRYEFJFBII4T
> mcdOICpAhV2wOiCzJWmiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3
> DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D
> AgIBKDANBgkqhkiG9w0BAQEFAASCAQAHdxnvzmNqANzRSJ6D5Y8PALfVuEyeAwS0ppjhleF5
> imZNFe4AEJAkqkKDggcf7z4JuAFhWBspnLLHOy9llQl2L9Eecf+EidRd3W2kHD5xeGjayzA1
> Jg5/kkOitWe3KcR4f5TcZoI9zP60XfMPEgHf83uh0q7AS4VeaQnm2DKCslxQAa8pNpqT2bf2
> wQTMyDWAqR7O/rKqF6DeWpHfbtuepR/UYxo3PLKnSaZorAIWEHRr1qzEHem0SuYQ48ZEf+pU
> 6zjHkHuAL/ao7l4mhlswcZ+6iwdrph1dUS6j+9AlOFkYUJmcaiHEwiZd8DZH0/y05dhJImqu
> 9h/Idf0EcppiAAAAAAAA
> --------------ms070801020106080500030006--
It's interesting that "the usual suspects" who are normally so quick to
pounce on newbies for exceeding the 4-line signature "limit" have been
eerily silent about Stephen's ridiculous recent 49-line exercises in
paranoia.
As so often, it's one rule for them and another rule for everyone else.
Flash Gordon
> On 7 Oct 2009 at 16:11, Stephen Sprunk wrote:
>> --
>> Stephen Sprunk "God does not play dice." --Albert Einstein
>> CCIE #3723 "God is an inveterate gambler, and He throws the
>> K5SSS dice at every possible opportunity." --Stephen Hawking
>>
>> --------------ms070801020106080500030006
>> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
<snip>
> It's interesting that "the usual suspects" who are normally so quick to
> pounce on newbies for exceeding the 4-line signature "limit" have been
> eerily silent about Stephen's ridiculous recent 49-line exercises in
> paranoia.
>
> As so often, it's one rule for them and another rule for everyone else.
I agree it's ridiculous, but I didn't see it because my news reader hid
it for me.
Stephen,
It is ridiculous adding that size of signature. With the forgeries that
have happened here, I can understand a desire to sign your messages, but
that really is going a LONG way over the top!
--
Flash Gordon
Default User
> Antoninus Twink wrote:
> > It's interesting that "the usual suspects" who are normally so
> > quick to pounce on newbies for exceeding the 4-line signature
> > "limit" have been eerily silent about Stephen's ridiculous recent
> > 49-line exercises in paranoia.
> I agree it's ridiculous, but I didn't see it because my news reader
> hid it for me.
Mine shows it as an attachment, which I don't open of course.
Brian
--
Day 248 of the "no grouchy usenet posts" project
Richard Heathfield
> Antoninus Twink wrote:
>> On 7 Oct 2009 at 16:11, Stephen Sprunk wrote:
>>> --
>>> Stephen Sprunk "God does not play dice." --Albert
>>> Einstein
>>> CCIE #3723 "God is an inveterate gambler, and He throws
>>> the
>>> K5SSS dice at every possible opportunity." --Stephen
>>> Hawking
>>>
>>> --------------ms070801020106080500030006
>>> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
>
> <snip>
>
>> It's interesting that "the usual suspects" who are normally so
>> quick to pounce on newbies for exceeding the 4-line signature
>> "limit" have been eerily silent about Stephen's ridiculous recent
>> 49-line exercises in paranoia.
>>
>> As so often, it's one rule for them and another rule for everyone
>> else.
>
> I agree it's ridiculous, but I didn't see it because my news reader
> hid it for me.
"The usual suspects" are, of course, Chuck Falconer. Why he has
stopped posting to the group, I don't know. But the fact that he has
stopped posting to the group may explain why he didn't complain about
the sig length.
> Stephen,
>
> It is ridiculous adding that size of signature.
It is? (Views source.) Oh. Yeah, perhaps a bit. The normal guideline
is 4, and 50-odd does seem a bit in excess of that.
> With the forgeries
> that have happened here, I can understand a desire to sign your
> messages, but that really is going a LONG way over the top!
Is it that huge a deal? 10 years ago, yes, okay. Maybe even five years
ago. But what proportion of Usenauts is on dialup nowadays?
Kenny McCormack
Antoninus Twink <nos...@nospam.invalid> wrote:
...
>It's interesting that "the usual suspects" who are normally so quick to
>pounce on newbies for exceeding the 4-line signature "limit" have been
>eerily silent about Stephen's ridiculous recent 49-line exercises in
>paranoia.
Yep.
>As so often, it's one rule for them and another rule for everyone else.
Yep.
Flash Gordon
I thought it included a few more than that. Of course, it could be that
everyone other than Chuck is a sock puppet of Chuck...
>> Stephen,
>>
>> It is ridiculous adding that size of signature.
>
> It is? (Views source.) Oh. Yeah, perhaps a bit. The normal guideline
> is 4, and 50-odd does seem a bit in excess of that.
You don't need anything like that bis a signature to sign messages
securely, so yes it is.
>> With the forgeries
>> that have happened here, I can understand a desire to sign your
>> messages, but that really is going a LONG way over the top!
>
> Is it that huge a deal? 10 years ago, yes, okay. Maybe even five years
> ago. But what proportion of Usenauts is on dialup nowadays?
I'm on a mobile phone connection because Broadband has not reached here
yet, so this the fastest I can get, and sometimes it is slow enough that
I get timeouts (at other times it is fast). I don't know how common slow
connections are though.
--
Flash Gordon
Richard Heathfield
Such as?
> Of course, it could be
> that everyone other than Chuck is a sock puppet of Chuck...
Or that you are believing what you're told by trolls instead of
considering the matter objectively. Right now I can only think of
/one/ other regular contributor who /might/ have voiced objections to
over-long sigs in comp.lang.c in the last few years[1]. (I won't name
him, because I'm probably misremembering.) It's far rarer than you
seem to think.
It's like topicality complaints - the trolls have me down as a topic
cop, but actually I'd like the topicality of the group to be wider
than it is, and I try to restrict my topicality moaning to occasions
when I think it actually matters.
<snip>
[1] I specifically exclude complaints made to CBF about /his/
overly-long sig. That was really just hypocrisy exposure. (Yes, I
know - we're all hypocrites.)
Keith Thompson
[...]
> Or that you are believing what you're told by trolls instead of
> considering the matter objectively. Right now I can only think of
> /one/ other regular contributor who /might/ have voiced objections to
> over-long sigs in comp.lang.c in the last few years[1]. (I won't name
> him, because I'm probably misremembering.) It's far rarer than you
> seem to think.
I've done so a few times. (I don't intend to entertain the trolls by
discussing this any further.)
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Stephen Sprunk
> On 7 Oct 2009 at 16:11, Stephen Sprunk wrote:
>> --
>> Stephen Sprunk "God does not play dice." --Albert Einstein
>> CCIE #3723 "God is an inveterate gambler, and He throws the
>> K5SSS dice at every possible opportunity." --Stephen Hawking
>>
>> --------------ms070801020106080500030006
>> --------------ms070801020106080500030006--
>
> It's interesting that "the usual suspects" who are normally so quick to
> pounce on newbies for exceeding the 4-line signature "limit" have been
> eerily silent about Stephen's ridiculous recent 49-line exercises in
> paranoia.
My .sig is only three lines. The S/MIME signature is in a separate body
part that, unless you're using a truly ancient newsreader, should be
hidden from view. The point of the 4-line .sig rule was to prevent
visual clutter, so a hidden body part cannot violate that rule.
As far as paranoia goes, with the recent spate of forgeries I deemed a
digital signature to be prudent. Perhaps the need has passed; I'll
consider turning it back off by default.
(If anyone can tell me how to get Tbird to make an S/MIME signature
smaller, without getting rid of it entirely, I'll gladly do so. My
apologies to Flash Gordon and other low-bandwidth users.)
> As so often, it's one rule for them and another rule for everyone else.
Now that the issue has been pointed out and they've complained about it,
are you happy? Did that make your world a better place, or were you
just looking for an excuse to take a potshot at others and try to bring
them down to your level?
S
Richard Heathfield
> Antoninus Twink wrote:
>> On 7 Oct 2009 at 16:11, Stephen Sprunk wrote:
>>> --
>>> Stephen Sprunk "God does not play dice." --Albert
>>> Einstein
>>> CCIE #3723 "God is an inveterate gambler, and He throws
>>> the
>>> K5SSS dice at every possible opportunity." --Stephen
>>> Hawking
>>>
>>> --------------ms070801020106080500030006
> ...
>>> --------------ms070801020106080500030006--
>>
>> It's interesting that "the usual suspects" who are normally so
>> quick to pounce on newbies for exceeding the 4-line signature
>> "limit" have been eerily silent about Stephen's ridiculous recent
>> 49-line exercises in paranoia.
>
> My .sig is only three lines. The S/MIME signature is in a separate
> body part that, unless you're using a truly ancient newsreader,
> should be
> hidden from view. The point of the 4-line .sig rule was to prevent
> visual clutter, so a hidden body part cannot violate that rule.
Really? I can sort of see that, but I thought it was mostly to cut
down on bandwidth consumption. For the record, on my newsreader the
sig does show up, but only as an entry in a MIME attachments table.
Personally I don't give two hoots, but is there any particular reason
you feel obliged to sign your articles digitally?
> As far as paranoia goes, with the recent spate of forgeries I deemed
> a digital signature to be prudent.
Oh, okay.
> Perhaps the need has passed;
I think "need" is a bit strong, but whatever - yeah, things seem to be
a bit calmer nowadays.
<snip>
Seebs
> My .sig is only three lines. The S/MIME signature is in a separate body
> part that, unless you're using a truly ancient newsreader, should be
> hidden from view. The point of the 4-line .sig rule was to prevent
> visual clutter, so a hidden body part cannot violate that rule.
slrn is not all that ancient. :)
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Flash Gordon
<snip>
> As far as paranoia goes, with the recent spate of forgeries I deemed a
> digital signature to be prudent. Perhaps the need has passed; I'll
> consider turning it back off by default.
>
> (If anyone can tell me how to get Tbird to make an S/MIME signature
> smaller, without getting rid of it entirely, I'll gladly do so.
I think all you need to do is use a certificate with fewer bits. I'm
guessing you are using a 1024 bit certificate, and I would have thought
256 or even 128 bits would be sufficient for Usenet postings.
> My
> apologies to Flash Gordon and other low-bandwidth users.)
Hey, it happens.
>> As so often, it's one rule for them and another rule for everyone else.
>
> Now that the issue has been pointed out and they've complained about it,
> are you happy? Did that make your world a better place, or were you
> just looking for an excuse to take a potshot at others and try to bring
> them down to your level?
Well, I just think you've gone far too big on it.
--
Flash Gordon
Richard
> Antoninus Twink wrote:
>> On 7 Oct 2009 at 16:11, Stephen Sprunk wrote:
>>> --
>>> Stephen Sprunk "God does not play dice." --Albert Einstein
>>> CCIE #3723 "God is an inveterate gambler, and He throws the
>>> K5SSS dice at every possible opportunity." --Stephen Hawking
>>>
>>> --------------ms070801020106080500030006
> ...
>>> --------------ms070801020106080500030006--
>>
>> It's interesting that "the usual suspects" who are normally so quick to
>> pounce on newbies for exceeding the 4-line signature "limit" have been
>> eerily silent about Stephen's ridiculous recent 49-line exercises in
>> paranoia.
>
> My .sig is only three lines. The S/MIME signature is in a separate body
> part that, unless you're using a truly ancient newsreader, should be
> hidden from view. The point of the 4-line .sig rule was to prevent
> visual clutter, so a hidden body part cannot violate that rule.
The point is that no one cares. Please stop spamming the group with your
paranoia.
>
> As far as paranoia goes, with the recent spate of forgeries I deemed a
> digital signature to be prudent. Perhaps the need has passed; I'll
> consider turning it back off by default.
"deemed to be prudent" eh? LOL.
>
> (If anyone can tell me how to get Tbird to make an S/MIME signature
> smaller, without getting rid of it entirely, I'll gladly do so. My
> apologies to Flash Gordon and other low-bandwidth users.)
Easy : don't bother. No one cares.
>
>> As so often, it's one rule for them and another rule for everyone else.
>
> Now that the issue has been pointed out and they've complained about it,
> are you happy? Did that make your world a better place, or were you
> just looking for an excuse to take a potshot at others and try to bring
> them down to your level?
>
> S
He was making a point that your garbage signing is unnecessary.
Stephen Sprunk
> On 2009-10-09, Stephen Sprunk <ste...@sprunk.org> wrote:
>> My .sig is only three lines. The S/MIME signature is in a separate body
>> part that, unless you're using a truly ancient newsreader, should be
>> hidden from view. The point of the 4-line .sig rule was to prevent
>> visual clutter, so a hidden body part cannot violate that rule.
>
> slrn is not all that ancient. :)
slrn has been around a long, long time and hasn't been changed much in
the last decade or so.
Still, there is good news! A few seconds with Google found:
http://web.archive.org/web/20080213183317/http:/piggo.com/~troy/slrn.php#demime
Using the Wayback Machine appears unnecessary:
http:/piggo.com/~troy/slrn.php#demime
Stephen Sprunk
> Stephen Sprunk wrote:
>> (If anyone can tell me how to get Tbird to make an S/MIME signature
>> smaller, without getting rid of it entirely, I'll gladly do so.
>
> I think all you need to do is use a certificate with fewer bits. I'm
> guessing you are using a 1024 bit certificate, and I would have thought
> 256 or even 128 bits would be sufficient for Usenet postings.
For better or worse, 2048-bit certs are what the well-known CAs are
issuing today, and there's no option to tell them to go smaller. The
root of the problem is that Tbird (and many other clients, I suspect)
includes the entire sender cert in every message, with no option to send
just the signature as many PGP users do.
I've turned off signing by default for my news account, though, so you
shouldn't have to deal with it anymore unless you correspond with me via
email or we have another rash of forgeries here.
Antoninus Twink
> As far as paranoia goes, with the recent spate of forgeries I deemed a
> digital signature to be prudent. Perhaps the need has passed; I'll
> consider turning it back off by default.
I wouldn't presume to speak for HfC, but it seems pretty clear to me
that you're one of the good guys in this group and so should have
nothing to fear from forgeries.
Despite the hysterical propaganda put out by the "regulars", I think I'm
right in saying that every single one of the forgeries was targeted at
someone who had been guilty of repeated unprovoked attacks on Han, and
repeteadly disrupted the newsgroup by passive-aggressive behavior.
> Now that the issue has been pointed out and they've complained about
> it, are you happy? Did that make your world a better place, or were
> you just looking for an excuse to take a potshot at others and try to
> bring them down to your level?
I agree that pointing out the hypocrisy and double-standards of the
"regulars" is largely a futile exercise that's unlikely ever to have any
positive effect: Their minds are closed. Still, sometimes it's nice to
be able to express one's frustration about it.
Frank
I'll have to think about this.
James, any word about water on the moon?
--
Frank
There's no liberal echo chamber in this country. There's a right-wing echo
chamber. I want to create a countervailing echo chamber.
~~ Al Franken, Chicago Tribune interview, on
Frank
> [1] I specifically exclude complaints made to CBF about /his/
> overly-long sig. That was really just hypocrisy exposure. (Yes, I
> know - we're all hypocrites.)
I'm not a hypocrite. I don't tell others what to do. Whatever happened to
Chuck? Did he finally give up his post as clc management?
--
Frank
Most of us here in the media are what I call infotainers...Rush Limbaugh is
what I call a disinfotainer. He entertains by spreading disinformation.
~~ Al Franken
Antoninus Twink
> Whatever happened to Chuck? Did he finally give up his post as clc
> management?
Maybe there's no internet access at the hospice.
Frank
I guess no one can elude the ultimate bitbucket.
James Kuyper
...
<OT>
> James, any word about water on the moon?
<http://www.nasa.gov/centers/ames/news/releases/2009/09-131AR.html> says
"The LCROSS team expects it to take several weeks of analysis before it
can make a definitive assessment of the presence or absence of water ice."
<\OT>
chad
I still use a US Robotics 56k external dial up modem for my internet
connection at home.
Richard Heathfield
<c65f2b2c-f19c-4d17...@s21g2000prm.googlegroups.com>,
chad wrote:
> On Oct 8, 3:19 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
>> Is [a big sig] that huge a deal? 10 years ago, yes, okay. Maybe
>> even five years ago. But what proportion of Usenauts is on dialup
>> nowadays?
>>
>
> I still use a US Robotics 56k external dial up modem for my internet
> connection at home.
That's the second respondent who reports low and costly bandwidth. It
is probably not unreasonable to suppose that there are a handful of
others in that situation too, who haven't spoken up. For such people,
I suppose a big sig /is/ still a big deal in terms of signal bits per
buck.
Maybe give it another five years, then.
Nobody
>> It's interesting that "the usual suspects" who are normally so quick to
>> pounce on newbies for exceeding the 4-line signature "limit" have been
>> eerily silent about Stephen's ridiculous recent 49-line exercises in
>> paranoia.
>
> My .sig is only three lines. The S/MIME signature is in a separate body
> part that, unless you're using a truly ancient newsreader, should be
> hidden from view.
If your ISP is like mine, the entire message will be "hidden from view"
(i.e. not available), as the signature constitutes a binary attachment,
and c.l.c isn't a "binaries" newsgroup.
> (If anyone can tell me how to get Tbird to make an S/MIME signature
> smaller, without getting rid of it entirely, I'll gladly do so.
Get a certificate from a CA that doesn't insist upon embedding two pages
of legalese in the certificate. Or just skip the certificate part
altogether and sign your messages with an "uncertified" key. Does it
actually matter whether some CA says that they believe that you really are
Stephen Sprunk?
Richard Bos
> Antoninus Twink wrote:
> > On 7 Oct 2009 at 16:11, Stephen Sprunk wrote:
> >> --
> >> Stephen Sprunk "God does not play dice." --Albert Einstein
> >> CCIE #3723 "God is an inveterate gambler, and He throws the
> >> K5SSS dice at every possible opportunity." --Stephen Hawking
> >>
> >> --------------ms070801020106080500030006
> >> Content-Type: application/x-pkcs7-signature; name="smime.p7s"
>
> <snip>
>
> > It's interesting that "the usual suspects" who are normally so quick to
> > pounce on newbies for exceeding the 4-line signature "limit" have been
> > eerily silent about Stephen's ridiculous recent 49-line exercises in
> > paranoia.
> >
> > As so often, it's one rule for them and another rule for everyone else.
>
> I agree it's ridiculous, but I didn't see it because my news reader hid
> it for me.
I have a good news _server_. It dropped this article in the bitbucket,
as it damn well should.
> Stephen,
>
> It is ridiculous adding that size of signature. With the forgeries that
> have happened here, I can understand a desire to sign your messages, but
> that really is going a LONG way over the top!
Not to mention that attached binaries don't belong in a text-only
newsgroup, and properly set up servers will drop such articles.
Richard
bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:RY6dnVVD19zYqE3X...@bt.com...
> In
> <c65f2b2c-f19c-4d17...@s21g2000prm.googlegroups.com>,
> chad wrote:
>
>> On Oct 8, 3:19 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> <snip>
>
>>> Is [a big sig] that huge a deal? 10 years ago, yes, okay. Maybe
>>> even five years ago. But what proportion of Usenauts is on dialup
>>> nowadays?
>>>
>>
>> I still use a US Robotics 56k external dial up modem for my internet
>> connection at home.
>
> That's the second respondent who reports low and costly bandwidth. It
> is probably not unreasonable to suppose that there are a handful of
> others in that situation too, who haven't spoken up. For such people,
> I suppose a big sig /is/ still a big deal in terms of signal bits per
> buck.
Might be more than you think. I used 56K dialup until a few weeks ago, as
that was the only option when staying with relatives who have no computers
but a telephone line, and the neighbours were inconsiderate enough to secure
their wifi networks.
Now that laptop has packed up, and the new one has only ethernet and wifi,
neither of which will just work anywhere.
> Maybe give it another five years, then.
Maybe, but only because phone jack sockets on computers are disappearing.
--
Bartc
Frank
> Frank wrote:
They knew pretty quickly with the enceladus fly-by that it was a bust.
It's not like the satellite is still transmitting on this one.
--
Frank
That's just stinkin' thinkin!
~~ Al Franken,
David Thompson
<sm...@spam.causeway.com> wrote:
> Stephen Sprunk wrote:
>
> <snip>
>
> > As far as paranoia goes, with the recent spate of forgeries I deemed a
> > digital signature to be prudent. Perhaps the need has passed; I'll
> > consider turning it back off by default.
> >
> > (If anyone can tell me how to get Tbird to make an S/MIME signature
> > smaller, without getting rid of it entirely, I'll gladly do so.
>
> I think all you need to do is use a certificate with fewer bits. I'm
> guessing you are using a 1024 bit certificate, and I would have thought
> 256 or even 128 bits would be sufficient for Usenet postings.
>
Stephen's *key* and thus signature is RSA 2K bits. 1K is adequate for
RSA for now, but not with huge margin; 512 or less has been broken for
years. A decent keygen program should let you select this, but I don't
know about Tbird specifically.
Elliptic-curve methods need less bits; ECDSA a little over 200 is
roughly equal to DSA 2K good enough for medium term, and less than 400
is comparable to 3K for decades -- barring unanticipated breakthroughs
(but are there any other kind?). Checking, I see that 3278 (and 3279)
in '02 standardized SMIME ECDSA (also ECDH and ECMQV, not relevant
here) but not mandatory. I don't know if Tbird implements them, but it
certainly has had time to do so.
ObVaguelyTopic: the crypto is probably written in C. <G>
Almost 200 bytes for P7 SignedAttrs doesn't help either.
But as already said, the real space hog is the cert, which doesn't
need to be sent on each message, and is signed by (a CA key which is)
RSA 4K, probably due to their (asserted) 30year (CA) validity, both of
which are silly. (OTOH it has only 88 bytes of 'legalese'.) Whether
and how you can get Tbird to omit the cert I don't know. It does
violate a SHOULD in 3850, but so do email-in-DN and RSA>2K.
io_x
"Frank" <fr...@example.invalid> ha scritto nel messaggio
news:1kdrxgz4sydrv$.67z7emiu1t3a$.dlg@40tude.net...
> In Dread Ink, the Grave Hand of Antoninus Twink Did Inscribe:
>
>> On 9 Oct 2009 at 23:04, Frank wrote:
>>> Whatever happened to Chuck? Did he finally give up his post as clc
>>> management?
>>
>> Maybe there's no internet access at the hospice.
>
> I guess no one can elude the ultimate bitbucket.
Yes how is CBFalconer?
for to be "bitbucket" i not see humans like that