[opensuse] gnu libc manual wrong?? concat (const char *str, ...) doesn't work...
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat
that explains why using mempcpy is better than using strcat or wcscat, but I run
into a segmentation fault attempting to use the suggested mempcpy replacement.
The code in libc.html (Ver: 2.15) is shown below. I had to add the declaration
for 's' to get past an undefined error (should have told me something right then).
char *
concat (const char *str, ...)
{
va_list ap;
size_t allocated = 100;
char *result = (char *) malloc (allocated);
if (result != NULL)
{
char *newp;
char *wp;
const char *s;
^^^^^^^^^^^^^^^^^^
va_start (ap, str);
wp = result;
for (s = str; s != NULL; s = va_arg (ap, const char *))
{
size_t len = strlen (s);
/* Resize the allocated memory if necessary. */
if (wp + len + 1 > result + allocated)
{
allocated = (allocated + len) * 2;
newp = (char *) realloc (result, allocated);
if (newp == NULL)
{
free (result);
return NULL;
}
wp = newp + (wp - result);
result = newp;
}
wp = mempcpy (wp, s, len);
}
/* Terminate the result string. */
*wp++ = '\0';
/* Resize memory to the optimal size. */
newp = realloc (result, wp - result);
if (newp != NULL)
result = newp;
va_end (ap);
}
return result;
}
I created a simple test program to verify the code:
#include
El 11/05/12 15:06, David C. Rankin escribió:
The compiler issues 2 warning (obviously the problem) that I cannot fix?
13:55 alchemy:~/dev/prg/ccpp/src-c/io/file> gcc -Wall -oct contest.c contest.c: In function ‘concat’: contest.c:61:4: warning: implicit declaration of function ‘mempcpy’ contest.c:61:9: warning: incompatible implicit declaration of built-in function ‘mempcpy’
Here is the bug in your code (and actually, a widely spread error, so no need to pull your hair on frustration :))
#include
#include #include #include #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif
This piece
#ifndef _GNU_SOURCE #define _GNU_SOURCE #endif
have to go BEFORE
#include
#include #include #include
CHeers. ps: gcc 4.7 with -O2 may axe your strcat 's and perform the optimization for you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/05/12 15:06, David C. Rankin escribió:
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat that explains why using mempcpy is better than using strcat or wcscat, but I run into a segmentation fault attempting to use the suggested mempcpy replacement. The code in libc.html (Ver: 2.15) is shown below. I had to add the declaration for 's' to get past an undefined error (should have told me something right then).
char * concat (const char *str, ...) { va_list ap; size_t allocated = 100; char *result = (char *) malloc (allocated);
if (result != NULL) { char *newp; char *wp; const char *s; ^^^^^^^^^^^^^^^^^^
Yes, there is this oversight also in the example code...
result = concat( myS1, myS2, myS3 );
^^ here here, missing sentinel ... should say. concat( myS1, myS2, myS3, NULL ); -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2012 03:00 PM, Cristian Rodríguez wrote:
El 11/05/12 15:06, David C. Rankin escribió:
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat that explains why using mempcpy is better than using strcat or wcscat, but I run into a segmentation fault attempting to use the suggested mempcpy replacement. The code in libc.html (Ver: 2.15) is shown below. I had to add the declaration for 's' to get past an undefined error (should have told me something right then).
char * concat (const char *str, ...) { va_list ap; size_t allocated = 100; char *result = (char *) malloc (allocated);
if (result != NULL) { char *newp; char *wp; const char *s; ^^^^^^^^^^^^^^^^^^
Yes, there is this oversight also in the example code...
result = concat( myS1, myS2, myS3 );
^^ here here, missing sentinel ... should say.
concat( myS1, myS2, myS3, NULL );
Christian, Thank you! Moving the _GNU_SOURCE define solved the compiler warnings and it now compiles on gcc 4.6 and 4.7 without warning. However... I think the code hates me. Looking at concat, it is supposed to return the pointer to the null terminated concatenated string. I thought that was what it was doing with '*wp++ = '\0';' before calling realloc. --Nope, you are correct, it works fine as long as I concatenate a NULL by sending it as the last string. Thanks! Works either way on gcc 4.7: fprintf ( stderr, "The result is: %s\n", concat( myS1, myS2, myS3, NULL )); or char * result; result = concat( myS1, myS2, myS3, NULL ); fprintf ( stderr, "The result is: %s\n", result); 15:49 providence:~/dev/prg/ccpp/src-c/io/file> gcc -Wall -oct contest.c 15:49 providence:~/dev/prg/ccpp/src-c/io/file> ./ct myS1: This is the beginning myS2: of my string to test myS3: libc manual concat. The result is: This is the beginning of my string to test libc manual concat. Now to change it so it automatically add the NULL :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/05/12 16:53, David C. Rankin escribió:
Now to change it so it automatically add the NULL :)
No ! the person that wrote the example knew what was doing ! just annotate the function with __attribute__ ((sentinel)) and GCC will warn you if you are missing the final NULL. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2012 04:49 PM, Cristian Rodríguez wrote:
El 11/05/12 16:53, David C. Rankin escribió:
Now to change it so it automatically add the NULL :)
No ! the person that wrote the example knew what was doing !
just annotate the function with __attribute__ ((sentinel)) and GCC will warn you if you are missing the final NULL.
Wow! You spend ...way... too much time with gcc :) I found it and it makes sense -- this is the first time I have stumbled across this attribute: sentinel This function attribute ensures that a parameter in a function call is an explicit NULL. The attribute is only valid on variadic functions. By default, the sentinel is located at position zero, the last parameter of the function call. If an optional integer position argument P is supplied to the attribute, the sentinel must be located at position P counting backwards from the end of the argument list. __attribute__ ((sentinel)) is equivalent to __attribute__ ((sentinel(0))) Works too! With the attribute declared, attempting to pass the parameter list without an explicit NULL provides a nice warning: char * concat (const char *str, ...) __attribute__ ((sentinel)); ~/dev/io/file> gcc -Wall -oct contest.c contest.c: In function ‘main’: contest.c:28:3: warning: missing sentinel in function call [-Wformat] Adreas, This would be a great place in the manual for 2.16 to illustrate this functionality. It may already be in the manual somewhere, but it wouldn't help to include it here since you will already be making changes to the missing declaration for 's'. The more examples of it that are spread around the manual, the less dust section 6.30 will collect :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, May 11, 2012 22:00:01 Cristian Rodríguez wrote:
El 11/05/12 15:06, David C. Rankin escribió:
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat
that explains why using mempcpy is better than using strcat or wcscat, but I run into a segmentation fault attempting to use the suggested mempcpy replacement. The code in libc.html (Ver: 2.15) is shown below. I had to add the declaration for 's' to get past an undefined error (should have told me something right then).
char * concat (const char *str, ...) {
va_list ap; size_t allocated = 100; char *result = (char *) malloc (allocated);
if (result != NULL)
{
char *newp; char *wp; const char *s;
^^^^^^^^^^^^^^^^^^
Yes, there is this oversight also in the example code...
I'm going to change this in the glibc manual for glibc 2.16.
result = concat( myS1, myS2, myS3 );
^^ here here, missing sentinel ... should say.
concat( myS1, myS2, myS3, NULL );
It's even in the example code: /* @r{This function concatenates arbitrarily many strings. The last} @r{parameter must be @code{NULL}.} */ -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/05/12 15:06, David C. Rankin escribió:
main (int argc, char **argv) {
char * myS1 = "This is the beginning"; char * myS2 = " of my string to test"; char * myS3 = " libc manual concat."; char * result;
Oh, and that does not do what you really mean ;) Use const char mySn[] = "...." I will let a known tyrant to explain it for you hehe :) http://gamesfromwithin.com/the-const-nazi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2012 05:10 PM, Cristian Rodríguez wrote:
El 11/05/12 15:06, David C. Rankin escribió:
main (int argc, char **argv) {
char * myS1 = "This is the beginning"; char * myS2 = " of my string to test"; char * myS3 = " libc manual concat."; char * result;
Oh, and that does not do what you really mean ;)
Use const char mySn[] = "...."
I will let a known tyrant to explain it for you hehe :) http://gamesfromwithin.com/the-const-nazi
Hmm, Now I'm curious. I have always seen string initializations allowed either way: char *myStr = "blah" or char myStr[] = "blah" To be warned of later attempts to modify constant strings, then the const type modifier is suggested, but I still don't see the difference between: const char *myStr = "blah" or const char myStr[] = "blah" Is there some difference in where/how storage is allocated between the two? Eg. from this example above: const char *myS1 = "This is the beginning"; const char myS2[] = " of my string to test"; const char *myS3 = " libc manual concat."; All seem to do the same thing?? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin said the following on 05/14/2012 02:59 PM:
Eg. from this example above:
const char *myS1 = "This is the beginning"; const char myS2[] = " of my string to test"; const char *myS3 = " libc manual concat.";
All seem to do the same thing??
Oh? Did you look at the generated code? (I've done that in the past to prove a point to know-nothing management!) -- Marketing is the science of convincing us that What You Get Is What You Want. -- John Carter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 14/05/12 14:59, David C. Rankin escribió:
On 05/11/2012 05:10 PM, Cristian Rodríguez wrote:
El 11/05/12 15:06, David C. Rankin escribió:
All seem to do the same thing??
Please read www.akkadia.org/drepper/dsohowto.pdf section 2.4 to know the difference. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
El 14/05/12 14:59, David C. Rankin escribió:
All seem to do the same thing??
Please read www.akkadia.org/drepper/dsohowto.pdf section 2.4 to know the difference.
Wow! Thanks for the link to that document, Cristian. And thanks to Ulrich for writing it! Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/14/2012 03:04 PM, Cristian Rodríguez wrote:
El 14/05/12 14:59, David C. Rankin escribió:
On 05/11/2012 05:10 PM, Cristian Rodríguez wrote:
El 11/05/12 15:06, David C. Rankin escribió:
All seem to do the same thing??
Please read www.akkadia.org/drepper/dsohowto.pdf section 2.4 to know the difference.
Oops, sorry Christian -- you will get 2 -- forgot to change the address...
Grr... Thank you! If I understood what I read, then for the benefit of those that didn't read it: char *str = "foo"; and char str[] = "foo"; are NOT the same thing. The meaningful difference, according to Drepper, being that the first declaration creates a variable named 'str' with its initial value being a 'pointer to' the string "foo". This requires the use of a variable in the non-sharable data segment and a relocation to initialize it with the pointer. The second declaration of char str[] = "foo"; simply creates a name for the sequence of bytes that initially contain "foo". The name for the sequence of bytes is not variable and cannot change, it is 'str' forever. Of course the bytes pointed to by 'str' can change. That is all new to me. Thank you Christian. When given the option to initialize with char *str or char str[], it shall be char str[] from now on. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 05/14/2012 03:04 PM, Cristian Rodríguez wrote:
El 14/05/12 14:59, David C. Rankin escribió:
On 05/11/2012 05:10 PM, Cristian Rodríguez wrote:
El 11/05/12 15:06, David C. Rankin escribió:
All seem to do the same thing??
Please read www.akkadia.org/drepper/dsohowto.pdf section 2.4 to know the difference.
Oops, sorry Christian -- you will get 2 -- forgot to change the address...
Grr... Thank you! If I understood what I read, then for the benefit of those that didn't read it:
char *str = "foo"; and char str[] = "foo";
are NOT the same thing. The meaningful difference, according to Drepper, being that the first declaration creates a variable named 'str' with its initial value being a 'pointer to' the string "foo". This requires the use of a variable in the non-sharable data segment and a relocation to initialize it with the pointer.
The second declaration of char str[] = "foo"; simply creates a name for the sequence of bytes that initially contain "foo". The name for the sequence of bytes is not variable and cannot change, it is 'str' forever. Of course the bytes pointed to by 'str' can change.
That is all new to me. Thank you Christian. When given the option to initialize with char *str or char str[], it shall be char str[] from now on.
I spent a semester writing in C, but debugging the same code at the assembly language level, and your interpretation is correct. Lets look at what the assembler puts out from a sample input file stringtest.c: 1 char *str1 = "foo"; 2 char str2[]= "bar"; 3 main() 4 { 5 char *str3 = "first_local"; 6 char str[] = "second_local"; 7 } gcc -S stringtest.c produced the following 32-bit 80x86 assembler file Original .s file has no # comments. All comments are mine. Lines with ## are ones I have inserted for clarification. Lines with ##>> are ones I have inserted with the C source code I have inserted #----- lines for readability key: # comment .THISISALABEL: #another comment THISISALABELTOO: .assemblerdirective [argument] .file "stringtest.c" ##>> 1 char *str1 = "foo"; .globl str1 # begin working on global variable str1 ## ---- first allocate a string of characters .section .rodata # mark this area as READ ONLY data .LC0: # insert generic label in address to mark first string's location .string "foo" # characters 'f' 'o' 'o' '\0' placed in memory image #----------------------------------------- .data # end readonly section, begin mutable data .align 4 # make sure next label is aligned on a 4-byte boundary .type str1, @object # str1 is the label of a variable. .size str1, 4 # 4 bytes reserved (32-bit pointer) for str1 ## 4th byte is the terminating '\0' character. ## -- str1: # label for first declared variable, str1 in address .long .LC0 # str1 initialized with address of generic label LC0 # i.e. str1 = points to 'f' 'o' 'o' '\0' allocated above ## -------------------------------------------------------------------------------------- ##>> 2 char str2[]= "fubar"; .globl stri2 # begin working on global variable stri2 .type stri2, @object # stri2 is the label of a variable .size stri2, 6 # 6 bytes reserved for stri2 stri2: # label for 2nd global variable, stri2, at start # of the 6-byte block .string "fubar" # which is filled with 'f' 'u' 'b' 'a' 'r' '\0' ##-------------------------------------------------------------------------------- .section .rodata # start READ ONLY data section. .LC1: # generic label for 3rd string location .string "first_local" # 17 chars 'f' 'i' 'r' .... 'c' 'a' 'l' '\0' ##>> 3 main () .text # now generating executable code .globl main # main is a label with global scope .type main, @function # main is a function main: # locate label main in the address space ##>> 4 { .LFB0: # locate LFB0 (Label Function Begin 0) in address space. .cfi_startproc # Begin standard gcc function preamble pushl %ebp # standard gcc function preamble .cfi_def_cfa_offset 8 # standard gcc function preamble .cfi_offset 5, -8 # standard gcc function preamble movl %esp, %ebp # standard gcc function preamble .cfi_def_cfa_register 5 # standard gcc function preamble subl $32, %esp # last line of standard function preamble ##note ebp is as the frame-pointer. Local variables are allocated in the function's frame. ## all local variables are addressed as offset(%ebp). Note that frame grows downward. ## 5 char *string3 = "first_local"; movl $.LC1, -4(%ebp) # initialize mem:(ebp-4)~(ebp-7) to point at LC1 ## remember LC1 is in a read-only block. ## 6 char string4 = "second_local"; ## string4 located at mem:(ebp-17), ends at mem:(ebp-5) movl $1868785011, -17(%ebp) # mem:(ebp-17)~(ebp-14) with 's' 'e' 'c' 'o' movl $1818190958, -13(%ebp) # mem:(ebp-13)~(ebp-10) with 'n' 'd' '_' 'l' movl $1818321775, -9(%ebp) # mem:(ebp-9 )~(ebp-6 ) with 'o' 'c' 'a' 'l' movb $0, -5(%ebp) # mem:(ebp-5)='\0' ## 7 } leave .cfi_restore 5 # standard end of function produced by gcc .cfi_def_cfa 4, 4 # standard end of function produced by gcc ret # standard end of function produced by gcc .cfi_endproc # standard end of function produced by gcc .LFE0: # Label Function End 0 ## --------- appendix of stuff added by GCC and SUSE ---------- .size main, .-main .ident "GCC: (SUSE Linux) 4.6.2" .section .comment.SUSE.OPTs,"MS",@progbits,1 .string "ospwg" .section .note.GNU-stack,"",@progbits -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 11 May 2012 14:06:03 David C. Rankin wrote:
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat that explains why using mempcpy is better than using strcat or wcscat, but I run into a segmentation fault attempting to use the suggested mempcpy replacement. The code in libc.html (Ver: 2.15) is shown below. I had to add the declaration for 's' to get past an undefined error (should have told me something right then).
char * concat (const char *str, ...) { va_list ap; size_t allocated = 100; char *result = (char *) malloc (allocated);
if (result != NULL) { char *newp; char *wp; const char *s; ^^^^^^^^^^^^^^^^^^
va_start (ap, str);
wp = result; for (s = str; s != NULL; s = va_arg (ap, const char *)) { size_t len = strlen (s);
/* Resize the allocated memory if necessary. */ if (wp + len + 1 > result + allocated) { allocated = (allocated + len) * 2; newp = (char *) realloc (result, allocated); if (newp == NULL) { free (result); return NULL; } wp = newp + (wp - result); result = newp; }
wp = mempcpy (wp, s, len); }
/* Terminate the result string. */ *wp++ = '\0';
/* Resize memory to the optimal size. */ newp = realloc (result, wp - result); if (newp != NULL) result = newp;
va_end (ap); }
return result; }
I created a simple test program to verify the code:
#include
#include #include #include #ifndef _GNU_SOURCE #define _GNU_SOURCE #endif
/* combine strings efficiently */
char * concat (const char *str, ...);
int main (int argc, char **argv) {
char * myS1 = "This is the beginning"; char * myS2 = " of my string to test"; char * myS3 = " libc manual concat."; char * result;
fprintf ( stderr, "myS1: %s\nmyS2: %s\nmyS3: %s\n", myS1, myS2, myS3);
result = concat( myS1, myS2, myS3 ); fprintf ( stderr, "The result is: %s\n", result);
return 0; }
The compiler issues 2 warning (obviously the problem) that I cannot fix?
13:55 alchemy:~/dev/prg/ccpp/src-c/io/file> gcc -Wall -oct contest.c contest.c: In function ‘concat’: contest.c:61:4: warning: implicit declaration of function ‘mempcpy’ contest.c:61:9: warning: incompatible implicit declaration of built-in function ‘mempcpy’
The man page (on 11.4) shows the exact same use of mempcpy:
void *mempcpy(void *dest, const void *src, size_t n);
The runtime failure is on the line: 'wp = mempcpy (wp, s, len);' (the if is skipped due to length < 100 of all strings). I like the idea of sticking with the gnu libc guidance of using mempcpy instead of strcat or wcscat, especially with the manuals labeling of programmers that use strcat "as lazy and reckless", but if the suggested replacement doesn't work...
So what gives here? What am I not seeing? What say the gurus?
Isn't "memcpy" one of those dangerous copying routines? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat that explains why using mempcpy is better than using strcat or wcscat, but I run
NEVER use strcat() or wcscat(), as they are unbounded, and specifically designed input can be devised to create compromise system security using stack-busting techniques. Instead, always, Always, ALWAYS use strncat() or wcsncat() This has been known since the realease of the Morris Worm in 1987 (or was it 1988?), as the payload was delivered by abusing strcat() in every Sun or Vax which received tainted e-mail containing the payload. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/05/12 15:43, Dirk Gently escribió:
David C. Rankin wrote:
Guys,
I need a bit of help. I've tried to follow the example after wchar_t * wcscat that explains why using mempcpy is better than using strcat or wcscat, but I run
NEVER use strcat() or wcscat()
Yes, however in very recent GCC versions, it will try to axe them out if possible replacing it for safer/faster alternatives, this does not cover all possible cases (nor I am aware that effort to handle all cases was done) this is as long you are not using strict standards swtiches (like -ansi) and _GNU_SOURCE is defined...
Instead, always, Always, ALWAYS use strncat() or wcsncat()
And screw it up anyway ;-D these libc APIs are screwed up beyond repair and you should not use them either. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dirk Gently said the following on 05/12/2012 03:43 PM:
This has been known since the realease of the Morris Worm in 1987 (or was it 1988?), as the payload was delivered by abusing strcat() in every Sun or Vax which received tainted e-mail containing the payload.
I've been ranting on about buffer overflow for a couple of decades now, haranguing programming schools for not teaching how to avoid such egregious flaws as this and use use of inappropriate memory copy routines. Yes, you'd think by now they'd have learnt. Real Engineering, certainly the classes I attended in the 60s and 70s, used examples of classical failures and "Don't let me catch you doing anything stupid like this" -- and that was meant as a class of action, not a specific. So why can't programming - No way can you call it 'software engineering' despite what people like Steve McConnell[1] and James Moore[2] might wish - learn from past mistakes by teaching students to avoid the classical mistakes early on? But no, teachers simply don't seem interested in teaching programming for the real world, just grammar and, talking with many students from local community colleges and prospective hires, I find that the teachers use examples that have nothing to do with reliability, maintainability and correctness. The ideas that are norms in other fields of engineering such as those, such as working from detailed specifications, seem an anathema. Many of us here were brought up in a MIL-SPEC (or similar) world where the subtext was that errors and omissions cost not just much $ but also lives, often catastrophically ("There's a bit smoking hole in the ground and lots of people are dead!") For the likes of us, the whole 'first to market and never mind the bugs' attitude is JUST PLAIN WRONG! Anyone who has been there when things go pear shaped under fire know that Miller[3] was wrong; "Two" is a distraction never mind "five". Focus, focus, focus. [1] "After the Gold Rush: Creating a true profession of software engineering"; Microsoft, ISBN 0-7356-0877-6 [2] "Software Engineering Standards: A user's Road map" IEEE Computer Society; ISBN0-8186-8008-3 [3] Miller, G. A. "The magical number seven, plus or minus two: Some limits on our capacity for processing information". Psychological Review 63 (1956)(2): pp81–97. -- The use of COBOL cripples the mind; its teaching should, therefore,be regarded as a criminal offence. -- E.W. Dijkstra -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Dirk Gently said the following on 05/12/2012 03:43 PM:
This has been known since the realease of the Morris Worm in 1987 (or was it 1988?), as the payload was delivered by abusing strcat() in every Sun or Vax which received tainted e-mail containing the payload.
I've been ranting on about buffer overflow for a couple of decades now, haranguing programming schools for not teaching how to avoid such egregious flaws as this and use use of inappropriate memory copy routines. Yes, you'd think by now they'd have learnt.
Real Engineering, certainly the classes I attended in the 60s and 70s, used examples of classical failures and "Don't let me catch you doing anything stupid like this" -- and that was meant as a class of action, not a specific. So why can't programming - No way can you call it 'software engineering' despite what people like Steve McConnell[1] and
I take anything said or written by someone in Microsoft with not a grain of salt, but an entire bucket.
James Moore[2] might wish - learn from past mistakes by teaching students to avoid the classical mistakes early on?
Well, there is one good thing about software engineering programs: because now these students are classified as engineers, they're getting exposure to real engineering profs as the engineering degree requirements mandate some exposure to actual engineering programs. Yes, the SWE profs are just renamed CS profs (with all the problems that entails). When I was at Purdue, I noticed a HUGE difference between the profs who taught programming in the CS department (pie in the sky; programming assignments which focussed on using a programming technique rather than whether that was the appropriate technique for solving the problem -- if you want to assign a project using linked lists, choose a problem in which linked lists is the most appropriate solution ... not one in which arrays are more are far more appropriate for reasons such as efficiency, etc.)
But no, teachers simply don't seem interested in teaching programming for the real world, just grammar and, talking with many students from local community colleges and prospective hires, I find that the teachers use examples that have nothing to do with reliability, maintainability and correctness. The ideas that are norms in other fields of engineering such as those, such as working from detailed specifications, seem an anathema.
CS profs seem to be in la-la land. But all of my EE profs did teach "real world" programming.
Many of us here were brought up in a MIL-SPEC (or similar) world where the subtext was that errors and omissions cost not just much $ but also lives, often catastrophically ("There's a bit smoking hole in the ground and lots of people are dead!") For the likes of us, the whole 'first to market and never mind the bugs' attitude is JUST PLAIN WRONG!
Anyone who has been there when things go pear shaped under fire know that Miller[3] was wrong; "Two" is a distraction never mind "five". Focus, focus, focus.
[1] "After the Gold Rush: Creating a true profession of software engineering"; Microsoft, ISBN 0-7356-0877-6 [2] "Software Engineering Standards: A user's Road map" IEEE Computer Society; ISBN0-8186-8008-3 [3] Miller, G. A. "The magical number seven, plus or minus two: Some limits on our capacity for processing information". Psychological Review 63 (1956)(2): pp81–97.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dirk Gently said the following on 05/13/2012 05:04 PM:
No way can you call it 'software engineering' despite what people like Steve McConnell[1] and
I take anything said or written by someone in Microsoft with not a grain of salt, but an entire bucket.
Indeed, but Steve's book was published, as many serious works are, by Microsoft Press. Microsoft does have a good research arm, just as in its time IBM-as-the-evil-empire did. The left hand didn't know what the right hand was doing, so to speak. Microsoft "Fellows", like IBM "Fellows" have done some serious work and contributed to the field. Do not presume to think that just because both Microsoft and IBM produced godamnawful code and used questionable marketing practices that everything done in their name was Evil Steve was the editor in chief of the IEEE Software Magazine, and is on the board that developed the IEEE Software Engineering Body of Knowledge. At the time he wrote "After the Gold Rush" he worked for Construx. http://www.stevemcconnell.com/ I very strongly recommend that you read "After The Gold Rush" (In my opinion V1 was better than V2) before casting aspersion. -- There is no use whatever trying to help people who do not help themselves. You cannot push anyone up a ladder unless he be willing to climb himself. - Andrew Carnegie -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dirk Gently said the following on 05/13/2012 05:04 PM:
CS profs seem to be in la-la land. But all of my EE profs did teach "real world" programming.
Just so. I took a course that would be classified as EE in the USA but was simply "Electronics". The people doing what you might think of as "CS" were doing "Cybernetics". There wasn't a lot of difference because most of the profs in the computing department were heavily involved with the hardware and doing "Control Systems" and other practical work rather than abstract things and the profs in "Electronics" were doing things that needed computers to analyse the data on control stuff in the lab. I got involved in a microprogrammed bit slice thngie that was to do gigahertz FFT samples from a radio telescope using 1MHz TTL as a front end for was eventually was a PDP-11 when funding arrived. -- Enter any 11-digit prime number to continue. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Dirk Gently said the following on 05/13/2012 05:04 PM:
CS profs seem to be in la-la land. But all of my EE profs did teach "real world" programming.
Just so. I took a course that would be classified as EE in the USA but was simply "Electronics".
Depending on the course material it could be EE or it could be ET (Electrical Technology).
The people doing what you might think of as "CS" were doing "Cybernetics". There wasn't a lot of difference because most of
This was at Purdue -- the FIRST Computer Science department in the world.
the profs in the computing department were heavily involved with the hardware and doing "Control Systems" and other practical work rather than abstract things and the profs in "Electronics" were doing things that needed computers to analyse the data on control stuff in the lab.
That's analog circuits stuff, and has nothing to do with the teaching of programming techniques as a discipline.
I got involved in a microprogrammed bit slice thngie that was to do gigahertz FFT samples from a radio telescope using 1MHz TTL as a front end for was eventually was a PDP-11 when funding arrived.
Sounds fun. One of my projects writing a cycle-by-cycle simulator for some CPU circuitry passed out by the prof. Then we had the great fun(*) of writing microcode to implement the PDP-11 instruction set. (*) for varying values of "fun" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dirk Gently said the following on 05/14/2012 04:44 AM:
One of my projects writing a cycle-by-cycle simulator for some CPU circuitry passed out by the prof. Then we had the great fun(*) of writing microcode to implement the PDP-11 instruction set.
(*) for varying values of "fun"
Teaching "coding" (in particular in a specific language) and teaching *PROGRAMMING* are two entirely different things. I suspect many CS departments/profs do the former without doing the latter. -- The master worries about the work, and the apprentice worries about the tools. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Dirk Gently said the following on 05/14/2012 04:44 AM:
One of my projects writing a cycle-by-cycle simulator for some CPU circuitry passed out by the prof. Then we had the great fun(*) of writing microcode to implement the PDP-11 instruction set.
(*) for varying values of "fun"
Teaching "coding" (in particular in a specific language) and teaching *PROGRAMMING* are two entirely different things. I suspect many CS departments/profs do the former without doing the latter.
You're absolutely right. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/13/2012 04:04 PM, Dirk Gently wrote:
Well, there is one good thing about software engineering programs: because now these students are classified as engineers, they're getting exposure to real engineering profs as the engineering degree requirements mandate some exposure to actual engineering programs. Yes, the SWE profs are just renamed CS profs (with all the problems that entails).
You call people who work on routers 'Network Engineers' and instead of programmers, people like to use the label 'Software Engineers', but engineering, in its true sense, is much more than the mastery of any syntactical idiom. Both provide the indispensable tools for today's engineering, but I have yet to see a seal requirement associated with the two. Engineering, in its purest form is more than the knowledge or understanding of physical principles, it is the value of the physical world applied to the betterment of mankind. There is a vast distinction between 'knowledge' and 'value' in cognitive taxonomy that it illustrative of the difference between software and mechanical engineering. While both can be responsible for the smoking hole, the liability does not rest on the shoulders of the software engineer. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin said the following on 05/14/2012 03:20 PM:
Engineering, in its purest form is more than the knowledge or understanding of physical principles, it is the value of the physical world applied to the betterment of mankind. There is a vast distinction between 'knowledge' and 'value' in cognitive taxonomy that it illustrative of the difference between software and mechanical engineering.
While both can be responsible for the smoking hole, the liability does not rest on the shoulders of the software engineer.
My first job out of university was with a military aviation firm. (Hence the "big smoking hole" quote.) In one of our orientation sessions the first month this issue of liability and responsibility was addressed and the profession of engineering brought into focus. Yes, someone had to sign off on the design and implementation. Since Aviation amounts to software control of the hardware, software is an intrinsic part of engineering. A couple of the new hires insisted they were programmers and not engineers. Perhaps they associated 'engineers' with the grime covered men driving steam engines or something, but they they were insistent that software was not an engineering profession. They were terminated on the spot. It was made very clear to us that liability rested on our shoulders whether we tightened nots and bolt, soldered joints or wrote code. During my time there I was an interplay backward and forward of algorithms being implemented in software and hardware as technology, space, power consumption and other constraints changed. But if you are not willing to take responsibility for your actions, why should you claim to have freedom of choice, free will? -- The scars of others should teach us caution. -- Saint Jerome, Letter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 05/13/2012 04:04 PM, Dirk Gently wrote:
Well, there is one good thing about software engineering programs: because now these students are classified as engineers, they're getting exposure to real engineering profs as the engineering degree requirements mandate some exposure to actual engineering programs. Yes, the SWE profs are just renamed CS profs (with all the problems that entails).
You call people who work on routers 'Network Engineers'
I don't. I call them technicians. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-13 01:03, Anton Aylward wrote:
For the likes of us, the whole 'first to market and never mind the bugs' attitude is JUST PLAIN WRONG!
You tell that to the bosses. They know not anything about programming, just money. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xBH4ACgkQIvFNjefEBxpifQCgqfqPmqnRE8s6fSAtdg1V95hP jR0AoMtxMvY6UI3V1Wi7O1V3O4ECEzoS =ZRYJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2012-05-13 01:03, Anton Aylward wrote:
For the likes of us, the whole 'first to market and never mind the bugs' attitude is JUST PLAIN WRONG!
You tell that to the bosses. They know not anything about programming, just money.
What's needed is some liability lawsuits. All of these "Not fit for any purpose" on software packaging are just so much nonsense. I would argue in court that they are nothing less than quaint decoration, because if the software vendor REALLY believed that the software is not fit for any puropose, then they wouldn't have gone to the trouble of advertising its capabilities (both in the media and on the package itself) and writing and distributing user manuals expressing EXACTLY what the software is supposed to do (regardless of whether it actually does it or not). Once management finds out that legally defending defective software takes all the profit out of the "We got our bugware to market first" strategy, we will see a change. Product liability law doesn't tolerate this sort of shoddyness for even a simple lawnmower, why should it be tolerated in software which has far greater impact on humanity? [And just for the record, I think that there needs to be a MAJOR reduction in medical malpractice liability -- medicine is imprecise, no doctor can have perfect knowledge, and yet the lawyers portray any medical sub-optimal medical outcome as a travesty. Of course, part of this may be a natural result of the arrogance of so many MD's. They have the highest per capita rate of fatalities in amateur aviation, because they so many of them think that their MD degree makes them more knowledgeable about takeoff and landing conditions than the (professionals) who work in that airfield's tower every day.] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Andreas Jaeger -
Anton Aylward -
Carlos E. R. -
Cristian Rodríguez -
Dave Howorth -
David C. Rankin -
Dirk Gently -
ianseeks