Re: strings

Re: strings

[Don Hughes]

On 12 Jan 2005 at 12:30, Jason wrote:

> keep in mind that the spirit of this community is based upon
> volunteer effort and everyone pitching in however they can to
> help better the community as a whole.

Absolutely, and very appreciated.  But I did not read the 
previous posts as a demand, but more of frustration.  There are 
many of us who are not hackers, and for whom netfilter is only a 
small part of the job.  It can be frustrating to get a hundred 
reasons why you should not be doing something that, for whatever 
reason, you need to do anyway.

And, yes, it can be also be frustrating to answer the same 
question over and over and over; but maybe that points to a 
different issue in that the tutorials or documentation needs to 
be modified. Searching the archives and getting 0 or 2000 hits is 
not helpful.


..don  

support at microtechniques.com
White Plains, NY

strings

[Benjamin Herrenschmidt]

Hi folks !

I just noticed, as I was digging into (yet another) unrelated llvm
problem with my code, that sparse-llvm fails to compile something that
has a statement such as:

static char *foo = "Foo !\n";

It pukes in output_data(), where we have initializer non-NULL and
initializer->type is EXPR_STRING. So we hit the default: case which is
an assert(0);

Now a trivial "fix" below doesn't quite work:

diff --git a/sparse-llvm.c b/sparse-llvm.c
index 9226a21..f151939 100644
--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -1181,6 +1181,12 @@ static LLVMValueRef output_data(LLVMModuleRef module, struct symbol *sym)
 				initial_value = output_data(module, sym);
 			break;
 		}
+		case EXPR_STRING: {
+			const char *s = initializer->string->data;
+
+			initial_value = LLVMConstString(strdup(s), strlen(s) + 1, true);
+			break;
+		}
 		default:
 			assert(0);
 		}

That has two interesting effects. First, if llvm is compiled with asserts,
it pukes claiming that the initializer is of the wrong type. Now that's
odd because as far as I can tell, the type is an array of i8 ... and it
works if you don't build the asserts in llvm.

Mind you, I had that problem with a different program, which was using
the various "InContext" variants of the various functions rather than
the global context ones... because at one point I was using the global
context for one of the LLVMInt8Type and that made it fail (again worked
fine without asserts).

Looks like the assert internally to LLVM is a pointer comparison of
Type * so it has to resolve to -exactly- the same type object internally,
pretty touchy. Maybe throwing a cast might help.

The second effect however is that the result is not nice:

  .../...

@"<noident>" = private global [7 x i8] c"Foo !\0A\00"
@foo = private global i8* @"<noident>"

  .../...

I haven't quite manage to coerce it to just have a single @foo = <something>
so it looks like we need to separately define the storage (the string)
and foo as a pointer to it, unless I missed something.

I tried to use the same construct we use in pseudo_to_value() (I factored
it out) but that results in worse output, where it now names the string
(.str<N>) but then creates a <noident> ptr and then assigns that to foo...

LLVM is harder than it seems :-)

Cheers,
Ben.

strings

[André Coelho]

greeting...if youre interessed in string algorihtm check

https://andrealbergaria.github.io/


thanks in advnace


andre

Re: strings

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Thu, Apr 20, 2023 at 03:58:47AM +0100, André Coelho wrote:
> greeting...if youre interessed in string algorihtm check
> 
> https://andrealbergaria.github.io/
> 

Looks like above link is about hex arithmetic implemented using strings,
right?

And the licensing is similar to Qt: it is opensource (GPLed), but there is
a commercial offering for proprietary projects.

Also, on what use cases can your idea fit the kernel context? Or doesn't the
kernel already have the implementation yet? Perhaps better implement as
userspace library? If it is the case, I'd like to see actual patch series
implementing your idea (see Documentation/process/submitting-patches.rst for
how to submit your patch).

Thanks!

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: strings

[Willy Tarreau]

[dropped innocents from the CC list]

On Fri, Apr 21, 2023 at 11:20:58AM +0700, Bagas Sanjaya wrote:
> On Thu, Apr 20, 2023 at 03:58:47AM +0100, André Coelho wrote:
> > greeting...if youre interessed in string algorihtm check
> > 
> > https://andrealbergaria.github.io/
> > 
> 
> Looks like above link is about hex arithmetic implemented using strings,
> right?

It looks more like a reinvention of the classical multi-byte string
processing (memcmp, memcpy, memmove etc).

> Also, on what use cases can your idea fit the kernel context? Or doesn't the
> kernel already have the implementation yet?

Sure it does, look at __crypto_memneq() for example, or more generally
at any memcmp() or memcpy() implementation from the last 30 years, for
example in glibc.

Regards,
Willy

Re: strings

[Bagas Sanjaya]

On 4/21/23 13:34, Willy Tarreau wrote:

>> Looks like above link is about hex arithmetic implemented using strings,
>> right?
> 
> It looks more like a reinvention of the classical multi-byte string
> processing (memcmp, memcpy, memmove etc).
> 
>> Also, on what use cases can your idea fit the kernel context? Or doesn't the
>> kernel already have the implementation yet?
> 
> Sure it does, look at __crypto_memneq() for example, or more generally
> at any memcmp() or memcpy() implementation from the last 30 years, for
> example in glibc.
> 

Thanks for explanation! I don't have any serious C[++] programming
background, so I was confused when I wrote the original reply.

-- 
An old man doll... just what I always wanted! - Clara