7 May
2023
7 May
'23
8:54 p.m.
Hi,
perhaps someone has an idea where I can look into to solve this.
I am building iscan packages when upgrading, because I patched the source to
support later PNG and with some other fixes.
Unfortunately after last upgrade I noticed that the newly build version does
not work, however the version build on buster last year still does work.
It is the same code and same build process. I don't know where to start
looking.
I ran through strace and there are few differences around threads and mmap,
but as I am not so experienced, I can not decide if this is relevant.
Do you have any advice?
thanks
BR
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
8 May
8 May
11:47 p.m.
deloptes via tde-devels wrote:
I ran through strace and there are few differences
around threads and
mmap, but as I am not so experienced, I can not decide if this is
relevant.
I did some debugging and pinpointed sscanf. It is not reading strings
properly.
Do you have any idea what could be the reason for this?
see attached for an example where the format and the string are from the
code and configuration respectively
TGH I do not understand why it is using %as there, but if %s is used it does
not parse the hex values properly and segfaults when printing the strings.
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
9 May
9 May
12:24 a.m.
On Mon May 8 2023 16:47:56 deloptes via tde-devels wrote:
I did some debugging and pinpointed sscanf. It is not
reading strings
properly.
Do you have any idea what could be the reason for this?
see attached for an example where the format and the string are from the
code and configuration respectively
%as is looking for a float so let's ignore that.
If we switch back to %s it's looking for a string which would be
great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing
to remember is NEVER NEVER NEVER use scanf or any variant thereof.
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
--Mike
6:18 a.m.
Mike Bird via tde-devels wrote:
%as is looking for a float so let's ignore that.
I found out %as means do not store (strip) the terminator \0.
If we switch back to %s it's looking for a string
which would be
great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing
to remember is NEVER NEVER NEVER use scanf or any variant thereof.
What do you mean it works with gcc? I have debian with gcc-10 and it does
following:
$ ./test
String: interpreter usb 0x04b8
0x0142 /usr/lib/esci/libesci-interpreter-perfection-v330 /usr/share/esci/esfwad.bin
vendor 4b8
product 142
library (null)
firmware (null)
I am not the owner of this code. It was working for the past 6y and as
reported when compiled last year in Buster it works as well, but now
compiled in Bullseye is not working.
For me it is not the matter of using it or not, but a change somewhere
either in gcc (Buster was using gcc-8) or in the libraries.
Also regarding the memory allocated. You are right. It is working if I
allocate memory and use %s instead of %as.
Why, oh, why?!
Is there some kind of flag or option for the compiler?
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
6:57 a.m.
On Mon May 8 2023 23:18:45 deloptes via tde-devels wrote:
My test.c attached to my previous email - sorry I should have chosen a
different name to avoid confusion - works with gcc-10 and clang-11 in
Debian 11.7 Bullseye.
Mike Bird via tde-devels wrote:
Do you have a man page for that? The test code is not written
to handle non-terminated strings. How would it know the lengths?
%as is looking for a float so let's ignore
that.
I found out %as means do not store (strip) the terminator \0. If we switch
back to %s it's looking for a string which would be
great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing
to remember is NEVER NEVER NEVER use scanf or any variant thereof.
What do you mean it works with gcc? I have debian with gcc-10 and it does
following: $ ./test
String: interpreter usb 0x04b8
0x0142 /usr/lib/esci/libesci-interpreter-perfection-v330
/usr/share/esci/esfwad.bin vendor 4b8
product 142
library (null)
firmware (null)
I am not the owner of this code. It was working for the past 6y and as
reported when compiled last year in Buster it works as well, but now
compiled in Bullseye is not working.
For me it is not the matter of using it or not, but a change somewhere
either in gcc (Buster was using gcc-8) or in the libraries.
Also regarding the memory allocated. You are right. It is working if I
allocate memory and use %s instead of %as.
Why, oh, why?!
Is there some kind of flag or option for the compiler?
%a currently means floating point.
%as used to be a non-standard and incompatible way of asking for
memory to be assigned for the strings but it won't work unless you
use special flags. The standards-compliant way to assign memory
while scanning is %ms.
So a simple fix would be to change %as to %ms but it's hard to get
it right - you have to free(3) the allocated memory but only if the
sscanf actually some memory. The attached test3.c shows how to do
this in this simple case.
--Mike
8:39 a.m.
New subject: [SOLVED] iscan compiled on debian10 works and compiled on debian11 does not work
Mike Bird via tde-devels wrote:
My test.c attached to my previous email - sorry I should have chosen a
different name to avoid confusion - works with gcc-10 and clang-11 in
Debian 11.7 Bullseye.
OK, thank you!
This was the solution. The code takes care of freeing the memory, but your
example is excellent one.
Thank you
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
On Mon May 8 2023 23:18:45 deloptes via tde-devels
wrote:
There is some documentation to the code but not in this regards.
Mike Bird via tde-devels wrote:
Do you have a man page for that? The test code is not written
to handle non-terminated strings. How would it know the lengths?
%as is looking for a float so let's ignore
that.
I found out %as means do not store (strip) the terminator \0. If we switch back to %s it's looking for a string
which would be
great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing
to remember is NEVER NEVER NEVER use scanf or any variant thereof.
What do you mean it works with gcc? I have debian with gcc-10 and it does
following: > $ ./test
> String: interpreter usb 0x04b8
> 0x0142 /usr/lib/esci/libesci-interpreter-perfection-v330
> /usr/share/esci/esfwad.bin vendor 4b8
> product 142
> library (null)
> firmware (null)
>
> >
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
I am not the owner of this code. It was working for the past 6y and as
reported when compiled last year in Buster it works as well, but now
compiled in Bullseye is not working.
For me it is not the matter of using it or not, but a change somewhere
either in gcc (Buster was using gcc-8) or in the libraries.
Also regarding the memory allocated. You are right. It is working if I
allocate memory and use %s instead of %as.
Why, oh, why?!
Is there some kind of flag or option for the compiler?
%a currently means floating point.
%as used to be a non-standard and incompatible way of asking for
memory to be assigned for the strings but it won't work unless you
use special flags. The standards-compliant way to assign memory
while scanning is %ms.
So a simple fix would be to change %as to %ms but it's hard to get
it right - you have to free(3) the allocated memory but only if the
sscanf actually some memory. The attached test3.c shows how to do
this in this simple case.
--Mike 
6:41 a.m.
Anno domini 2023 Mon, 8 May 17:24:02 -0700
Mike Bird via tde-devels scripsit:
On Mon May 8 2023 16:47:56 deloptes via tde-devels
wrote:
Sorry to spoil the party, but on this page contains errors (I have not read further
) "read(fd, &len, sizeof(len));" is utterly BS.
I did some debugging and pinpointed sscanf. It is
not reading strings
properly.
Do you have any idea what could be the reason for this?
see attached for an example where the format and the string are from the
code and configuration respectively
%as is looking for a float so let's ignore that.
If we switch back to %s it's looking for a string which would be
great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing
to remember is NEVER NEVER NEVER use scanf or any variant thereof.
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
--Mike
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
6:57 a.m.
On Mon May 8 2023 23:41:03 Dr. Nikolaus Klepp via tde-devels wrote:
Sorry to spoil the party, but on this page contains errors (I have not read
further ) "read(fd, &len, sizeof(len));" is utterly BS.
That's a perfectly reasonable way to read a binary integer into len if you
know that the integer to be read is compatible with the size_t of the arch.
For example if you are merely piping data between parent and child processes.
However the result of the read should have been checked and then the data
read into len should also have been thoroughly checked.
The examples exist to point out the dangers of not validating lengths and
of confusing size_t, int, and unsigned int - all of which may be different.
--Mike
7:07 a.m.
Anno domini 2023 Mon, 8 May 23:57:00 -0700
Mike Bird via tde-devels scripsit:
On Mon May 8 2023 23:41:03 Dr. Nikolaus Klepp via
tde-devels wrote:
It's a good way to call for trouble when you have mixed architecture, which is by no
means a outerworldisch thing today. If you control both sides of the pipe and you spoiled
your own protocol ... don't know what to say, that would have been wrong anyways.
Sorry to spoil the party, but on this page contains errors (I have not read
further ) "read(fd, &len, sizeof(len));" is utterly BS.
That's a perfectly reasonable way to read a binary integer into len if you
know that the integer to be read is compatible with the size_t of the arch.
For example if you are merely piping data between parent and child processes. However the result of the read should have been
checked and then the data
read into len should also have been thoroughly checked.
The examples exist to point out the dangers of not validating lengths and
of confusing size_t, int, and unsigned int - all of which may be different.
--Mike
____________________________________________________
tde-devels mailing list -- devels(a)trinitydesktop.org
To unsubscribe send an email to devels-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesk…
--
Please do not email me anything that you are not comfortable also sharing with the NSA,
CIA ...
361
days inactive
363
days old
8 comments
3 participants
participants (3)
-
deloptes -
Dr. Nikolaus Klepp -
Mike Bird