Hi Alessandro,
On 15/8/21 18:08, Alessandro Vesely via Dng wrote:
I guess we all ended up developing something similar. My take:
http://www.tana.it/svn/zdkimfilter/trunk/src/cstring.h
http://www.tana.it/svn/zdkimfilter/trunk/src/cstring.c
It's harsh as it assumes the caller _always_ checks retu
On Thu 12/Aug/2021 13:12:29 +0200 Aitor wrote:
On 31/7/21 11:20, aitor wrote:
Sometimes I use the following buffer struct for dynamic allocation:
https://gitea.devuan.dev/aitor_czr/libnetaid/src/branch/master/backend_src/sbuf.c
I guess we all ended up developing something similar. My take
aitor said on Thu, 12 Aug 2021 13:41:44 +0200
>On 12/8/21 13:12, aitor wrote:
>> struct sbuf s __cleanbuf__(free_buf);
>I rectify:
>
>struct sbuf s __cleanbuf__;
>
>being:
>
>#define __cleanbuf__ __attribute__((cleanup(free_buf)))
I see the attraction, Aitor, but doing this has some downs
On 12/8/21 13:12, aitor wrote:
struct sbuf s __cleanbuf__(free_buf);
I rectify:
struct sbuf s __cleanbuf__;
being:
#define __cleanbuf__ __attribute__((cleanup(free_buf)))
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org
Hi,
On 31/7/21 11:20, aitor wrote:
On 31/7/21 3:02, Bruce Perens via Dng wrote:
If you want this, it's easy enough to allocate your own stack, and
write functions that allocate from it and release the allocation.
Sometimes I use the following buffer struct for dynamic allocation:
https://git
Hi
Thu, 29 Jul 2021 16:57:44 -0400 - Steve Litt :
> al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
> >
> >9) Write code to debug and log
>
> I'm not sure what you mean here. Do you mean to write errors and
> warnings to log files, or do you mean something more.
Both.
I do definitely mean
Le 30/07/2021 à 15:24, Enrico Weigelt, metux IT consult a écrit :
> On 21.07.21 14:36, Didier Kryn wrote:
>
>> I want to add to the comments that this alloca() function has been
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack.
>
> Wha
Hi,
On 31/7/21 3:02, Bruce Perens via Dng wrote:
If you want this, it's easy enough to allocate your own stack, and
write functions that allocate from it and release the allocation.
Sometimes I use the following buffer struct for dynamic allocation:
https://gitea.devuan.dev/aitor_czr/libnetai
If you want this, it's easy enough to allocate your own stack, and write
functions that allocate from it and release the allocation. If you were
writing in C++, you could make releasing the allocation automatic.
I think this illustrates why the kernel developers are taking Rust
seriously.
On Fri,
Enrico Weigelt, metux IT consult said on Fri, 30 Jul 2021 15:24:07 +0200
>In kernel space, we have the golden rule of not doing any larger stack
>allocations, even not larger fixed sized arrays.
Larger than how much? Surely
bestdistro[12]; strncpy(bestdistro, "Devuan", strlen("Devuan"));
would
On 21.07.21 14:36, Didier Kryn wrote:
I want to add to the comments that this alloca() function has been
added (by gcc ?) to work around a missing feature of the C language:
dynamic allocation on the stack.
What you *actually* want is not "on stack" (directly), but automatically
freed wh
On Thu, 29 Jul 2021 20:10:24 -0400, Hendrik wrote in message
<20210730001024.rjm4r3fxejkxe...@topoi.pooq.com>:
> On Thu, Jul 29, 2021 at 04:57:44PM -0400, Steve Litt wrote:
> > al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
> > >
> > >11) Document and document and document all the code (vars,
>
Hendrik Boom said on Thu, 29 Jul 2021 20:10:24 -0400
>On Thu, Jul 29, 2021 at 04:57:44PM -0400, Steve Litt wrote:
>> al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
>> >
>> >11) Document and document and document all the code (vars,
>> >functions, errors etc. ... all)
>>
>> I do that: Nobody e
On Thu, Jul 29, 2021 at 04:57:44PM -0400, Steve Litt wrote:
> al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
> >
> >11) Document and document and document all the code (vars, functions,
> >errors etc. ... all)
>
> I do that: Nobody else does. It really makes things difficult when I
> need to work
al3xu5 said on Thu, 29 Jul 2021 17:33:10 +0200
>
>9) Write code to debug and log
I'm not sure what you mean here. Do you mean to write errors and
warnings to log files, or do you mean something more.
>
>10) Handle all kind of errors
I know that's the *right* thing to do, and I do it often, bu
tempforever said on Thu, 29 Jul 2021 12:13:51 -0400
>Is this commandment (the code of one subroutine fitting into one
>screen) an absolute rule? What about, for example, assembly-language
>programming? Must I buy a bigger screen? :-)
>I will admit that I do very little assembly anymore, so this
Anno domini 2021 Thu, 29 Jul 10:57:50 -0700
spiralofh...@spiralofhope.com scripsit:
> On Thu, 29 Jul 2021 17:33:10 +0200
> al3xu5 wrote:
>
> > 11) Document and document and document all the code (vars, functions,
> > errors etc. ... all)
>
> It was mentioned earlier; variables and functions wou
On Thu, 29 Jul 2021 17:33:10 +0200
al3xu5 wrote:
> 11) Document and document and document all the code (vars, functions,
> errors etc. ... all)
It was mentioned earlier; variables and functions wouldn't need much
(if any) documentation if they were long and descriptive.
I like using short phras
On 7/29/21 9:13 AM, tempforever wrote:
Is this commandment (the code of one subroutine fitting into one screen)
an absolute rule? What about, for example, assembly-language
programming? Must I buy a bigger screen? :-)
I will admit that I do very little assembly anymore, so this wouldn't
affect
Is this commandment (the code of one subroutine fitting into one screen)
an absolute rule? What about, for example, assembly-language
programming? Must I buy a bigger screen? :-)
I will admit that I do very little assembly anymore, so this wouldn't
affect me much now. I have many routines in C t
Tue, 27 Jul 2021 07:31:12 -0700 - Josef Grosch :
> On 7/26/21 11:26 PM, tito via Dng wrote:
> > On Mon, 26 Jul 2021 22:53:02 -0400
> > Steve Litt wrote:
> >
> >> Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> >>
> >>> On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> >>>
On Tue, 27 Jul 2021 13:11:47 -0400
Steve Litt wrote:
> tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
>
>
> >Ten Commandments
> >
> > 1) use the least amount of code possible
> > 2) try harder and go to point 1
> > 3) if the code doesn't fit into one screen go to point 2
> > 4) always
On Tue, 27 Jul 2021 13:07:01 -0400
Steve Litt wrote:
> tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
>
>
> >Ten Commandments
> >
> > 1) use the least amount of code possible
> > 2) try harder and go to point 1
> > 3) if the code doesn't fit into one screen go to point 2
>
> Do you me
Josef Grosch via Dng said on Tue, 27 Jul 2021 07:31:12 -0700
>7) Pay attention to the scope of variables and functions.
LOL. When I was a lot younger and stupider, my C code enabling 40 data
entry people to input data crashed once or twice a day, costing about
1/2 hour of work for each (20 hours
Miles Fidelman said on Tue, 27 Jul 2021 09:59:49 -0400
Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> My feeling is, that you can not simply teach someone how to write
> safe software.
Why not? You can teach a person to do anything else. But maybe not
tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
>Ten Commandments
>
> 1) use the least amount of code possible
> 2) try harder and go to point 1
> 3) if the code doesn't fit into one screen go to point 2
> 4) always initialize your vars at declaration time
> 5) always set your vars to N
tito via Dng said on Tue, 27 Jul 2021 08:26:03 +0200
>Ten Commandments
>
> 1) use the least amount of code possible
> 2) try harder and go to point 1
> 3) if the code doesn't fit into one screen go to point 2
Do you mean if the code OF ONE SUBROUTINE doesn't fit into one screen,
go to point 2
On 7/26/21 11:26 PM, tito via Dng wrote:
On Mon, 26 Jul 2021 22:53:02 -0400
Steve Litt wrote:
Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
My feeling is, that you
Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
My feeling is, that you can not simply teach someone how to write
safe software.
Why not? You can teach a person to do anything else. But maybe not in
college, because college is built to make money, not to teach.
Consider the average t
On Tuesday, July 27th, 2021 at 7:26 AM, tito via Dng wrote:
> On Mon, 26 Jul 2021 22:53:02 -0400
> Steve Litt sl...@troubleshooters.com wrote:
> > Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
> > > On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> > > > Andreas Messer said on M
On Mon, 26 Jul 2021 22:53:02 -0400
Steve Litt wrote:
> Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
>
> >On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> >> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> >>
> >>
> >> >My feeling is, that you can not simply teac
Hendrik Boom said on Mon, 26 Jul 2021 17:21:24 -0400
>On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
>> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
>>
>>
>> >My feeling is, that you can not simply teach someone how to write
>> >safe software.
>>
>> Why not? You can
On Mon, Jul 26, 2021 at 11:48:53AM -0400, Steve Litt wrote:
> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
>
>
> >My feeling is, that you can not simply teach someone how to write safe
> >software.
>
> Why not? You can teach a person to do anything else. But maybe not in
> college, be
g4sra via Dng said on Mon, 26 Jul 2021 16:33:45 +
>On Monday, July 26th, 2021 at 4:48 PM, Steve Litt
> wrote:
>> Let's start with input field cleansing and
>> protection from errant pointers and buffer overflow. There are many
>> more:
>Yeah, that's what they taught me at college :).
OK,
<--snip-->
> > >
> > > Agreed, we must have all at least heard of Kevin Mitnick,
> There you go with assumptions, something you should never do. I have
> absolutely no idea who Kevin Mitnick is, I had never heard that name
> until you posted it.
>
> Rowland
It wasn't my intention to be educati
On Mon, 2021-07-26 at 16:33 +, g4sra via Dng wrote:
> On Monday, July 26th, 2021 at 4:48 PM, Steve Litt <
> sl...@troubleshooters.com> wrote:
> > Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
> >
> > > My feeling is, that you can not simply teach someone how to write
> > > safe softwa
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Monday, July 26th, 2021 at 5:39 PM, Dr. Nikolaus Klepp
wrote:
> Anno domini 2021 Mon, 26 Jul 16:33:45 +
>
> g4sra via Dng scripsit:
>
> > [...]
> >
> > > It takes some effort to learn, but I doubt it's rocket sc
Anno domini 2021 Mon, 26 Jul 16:33:45 +
g4sra via Dng scripsit:
> [...]
> > It takes some effort to learn, but I doubt it's rocket science
> Which is why they call it Computer Science, it's harder.
> Rocket Science has a formula for everything, even the top AI experts cannot
> formulate the i
On Monday, July 26th, 2021 at 4:48 PM, Steve Litt
wrote:
> Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
>
> > My feeling is, that you can not simply teach someone how to write safe
> > software.
>
> Why not? You can teach a person to do anything else. But maybe not in
> college, be
Andreas Messer said on Mon, 26 Jul 2021 09:38:23 +0200
>My feeling is, that you can not simply teach someone how to write safe
>software.
Why not? You can teach a person to do anything else. But maybe not in
college, because college is built to make money, not to teach. Consider
the average tex
On Sun, Jul 25, 2021 at 07:51:50PM -0400, Steve Litt wrote:
> g4sra via Dng said on Sun, 25 Jul 2021 10:26:46 +
>
>
> >And this is why ever sice I entered the profession I have maintained
> >that programmers should be vetted and certified in a similar manner to
> >other professions such as do
g4sra via Dng said on Sun, 25 Jul 2021 10:26:46 +
>And this is why ever sice I entered the profession I have maintained
>that programmers should be vetted and certified in a similar manner to
>other professions such as doctors and lawyers, carrying a similar
>social status. Only those with th
On Sunday, July 25th, 2021 at 6:53 PM, Simon Hobson
wrote:
> Andreas Messer a...@bastelmap.de wrote:
>
> > Once we had a crash in
> > simple limit switch device. As a result the high-rack robot pushed a
> > pallet in 15m height out of the rack. Fortunately, it was just another
> > robot which w
Andreas Messer wrote:
> Once we had a crash in
> simple limit switch device. As a result the high-rack robot pushed a
> pallet in 15m height out of the rack. Fortunately, it was just another
> robot which was destroyed (stood just below) - not a human being. Still
> a very expensive case for the
<--snip-->
> Why I'm so critical about letting it crash: I typically deal with stack
> sizes of no more around 2-8kB in automation devices and have to be careful
> with that. You can't simply let a newspaper printing machine's motor control
> crash, 1000's of newspaper pages would be trashed. Once
On Sat, Jul 24, 2021 at 05:35:10PM +0200, Didier Kryn wrote:
> However the manual of alloca() states that "There is no error
> indication if the stack frame cannot be extended." If the same would
> happen with automatic variables, I would expect a crash; otherwise it
> would be a serious fl
Le 22/07/2021 à 20:53, Andreas Messer a écrit :
> Hi,
>
> On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
>> There's a choice of options in GCC to deal with stack protection.
>> Eg: -fstack-check
>>
>> Plus a bunch of macros.
>>
>> They all deal with allocation of automati
Hi,
On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
> There's a choice of options in GCC to deal with stack protection.
> Eg: -fstack-check
>
> Plus a bunch of macros.
>
> They all deal with allocation of automatic variables. For alloca(),
> instead, there's explicitely
Le 21/07/2021 à 21:08, Andreas Messer a écrit :
> On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack. This lack has disapeared many years ago
>> ( don't know with which version of th
Bernard Rosset via Dng said on Wed, 21 Jul 2021 18:17:43 +0200
>> I've found a discussion between a developper and Lennart
>> Poeterring in which LP recommends the addition of this kind of
>> functions in Musl libc (which will certainly never happen). It's
>> slightly amusing how the author o
On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
> added (by gcc ?) to work around a missing feature of the C language:
> dynamic allocation on the stack. This lack has disapeared many years ago
> ( don't know with which version of the C standard) , with the following
> form of allocati
Le 21/07/2021 à 18:19, Tomasz Torcz a écrit :
> On Wed, Jul 21, 2021 at 06:00:15PM +0200, Didier Kryn wrote:
>> Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>>> I'll be projecting myself here, but I reckon shar
On Wed, Jul 21, 2021 at 06:00:15PM +0200, Didier Kryn wrote:
> Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
> >> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
> >
> > I'll be projecting myself here, but I reckon sharing the original
> > source rather than journ
I've found a discussion between a developper and Lennart Poeterring
in which LP recommends the addition of this kind of functions in Musl
libc (which will certainly never happen). It's slightly amusing how the
author of such a critical software as systemd lacks a culture of security.
Many t
Le 21/07/2021 à 16:51, Bernard Rosset via Dng a écrit :
>> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
> I'll be projecting myself here, but I reckon sharing the original
> source rather than journalistic articles whenever possible is best
> towards a tech-savvy audie
https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
I'll be projecting myself here, but I reckon sharing the original source
rather than journalistic articles whenever possible is best towards a
tech-savvy audience.
The source (included in above article) is here:
https:
Le 21/07/2021 à 15:47, William Gallafent via Dng a écrit :
> According to a man page I happen to have in front of me, “alloca()
> appeared in Version 32V AT&T UNIX.”
>
> I've certainly seen it in use on code originally written during the
> last millennium for SGI IRIX, and then ported to several ot
On Wed, 21 Jul 2021 at 13:36, Didier Kryn wrote:
> I want to add to the comments that this alloca() function has been
> added (by gcc ?) to work around a missing feature of the C language:
> dynamic allocation on the stack. This lack has disapeared many years ago
> ( don't know with which vers
Le 20/07/2021 à 22:08, Dr. Nikolaus Klepp a écrit :
> Just in case sombody missed it:
>
> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
>
> "Systemd, the Linux system and service manager that has largely
> replaced init as the master Linux startup and control program, h
goli...@devuan.org said on Tue, 20 Jul 2021 16:20:33 -0500
>On 2021-07-20 15:52, Joel Roth via Dng wrote:
>> On Tue, Jul 20, 2021 at 10:08:48PM +0200, Dr. Nikolaus Klepp wrote:
[snip]
>>> In a phrase, "that's bad, that's really bad."
>>
>> It seems that this is the tip of what will be be a
Dr. Nikolaus Klepp said on Tue, 20 Jul 2021 22:08:48 +0200
>Just in case sombody missed it:
>
>https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
The exploit happens by mounting something to a very long path, crashing
systemd.
I'd like to remind everyone that the s6 init sy
On 2021-07-20 15:52, Joel Roth via Dng wrote:
On Tue, Jul 20, 2021 at 10:08:48PM +0200, Dr. Nikolaus Klepp wrote:
Just in case sombody missed it:
https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
"Systemd, the Linux system and service manager that has largely
replaced
On Tue, Jul 20, 2021 at 10:08:48PM +0200, Dr. Nikolaus Klepp wrote:
> Just in case sombody missed it:
>
> https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
>
>
> "Systemd, the Linux system and service manager that has largely replaced init
> as the master Linux startup an
Just in case sombody missed it:
https://www.zdnet.com/article/nasty-linux-systemd-security-bug-revealed/
"Systemd, the Linux system and service manager that has largely replaced init
as the master Linux startup and control program, has always had its critics.
Now, with Qualys's discovery of a
64 matches
Mail list logo
