Patch for making 2.2.1 compile Under NCR MP-RAS (SVR4)

Seth Mos knuffie at
Thu Jul 12 20:51:28 GMT 2001

At 16:36 12-7-2001 -0400, John E. Malmberg wrote:
>On Thu, 12 Jul 2001, Seth Mos wrote:
> > At 12:00 12-7-2001 -0400, John E. Malmberg wrote:
> > >On Thu, 12 Jul 2001, Seth Mos wrote:
> > >
> > > > Hi,
> > > >
> > > > I have attached this patch for compiling samba-2.2.1 under NCR MP-RAS.
> > > > The patch is not intrusive and only changes the words TRUE and FALSE to
> > > > True and False because the C compiler on this system gives the 
> "Identifier
> > > > is undeclared" message.
> > >
> > >4.9 K Application / Octect stream attachment?
> >
> > Oops the mailer messed up.
> > I could send you the patch in the body.
>Actually there is a different mailing list for patches to be sent to.
>Patches should be in diff -u format and sent to samba-patches(@)

It was made with diff -urN so it should be fine. And it is not an octet-stream.

>They also should be done against code that is obtained from the CVS
>HEAD branch from the CVS server.  See and follow the

This can probably be retrofitted on HEAD without even looking at it.
It does not change code structure.

>I am not on the SAMBA team, so I do not know if there is a specific
>effort to not rely on common non-standard extensions or not.
>If there is, then I have some more patches that I can send in where
>they are requiring the presence of routines that I can not find
>documented in The Open Group's online reference, or they are using
>routines that either The Open Group or the LINUX documentation has
>declared obsolete, and recommends using a different routine.
>But these are all minor issues, and not showstoppers.

Otherwise it doesn;t compile, I call that a showstopper if you want to use 
it under NCR MP-RAS.
2.0.x works out of the box.

>It all depends on what degree of portability or Coding standard that
>the SAMBA Team is aiming for.  I have not seen any specific document, but
>then again, I have not looked.

Like I said, it might just have crept in over time.

>The problem with something small like this, is that so many programmers
>are used to those symbols being there, that the simplest route to long
>term maintenance is to insure that they are there.

if 99% percent of the code is in the right form I consider this a silly typo.

>Otherwise, you might fix it this time, and someone could add a new module
>to SAMBA with the same bug.

I'll see it when that happens, programming software is like shoving snow.
Once you get it out of the way, there is new snow waiting just behind you.

>The only way to stop that is if the SAMBA Team had some sort of automatic
>tool that insures that the code meets their standard.
>Sometimes it is just better to go with the flow, instead of trying to get
>things to be perfect.

We can try, and at least fix it for 2.2.2 :-)

I'll send the patch to the right mail addres in the mean time.

Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.

More information about the samba-technical mailing list