[go-nuts] methods on C types
Hi,
where is documented that methods can be created on C types ?
This works with go1.12.4, linux:
https://play.golang.org/p/gXpHCFOgDDg
package main
import (
"C"
"fmt"
)
func (i *C.int) Inc() {
*i++
}
func main() {
var i C.int
i.Inc()
fmt.Println(i)
}
Thanks
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: fatal error: 'config.h' file not found
Is it likely that *syslogd new generation* needs to be installed, together with its development libraries, *before* it can be included in a Go project? Or, quite possibly, just the development libraries? Lucio. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: fatal error: 'config.h' file not found
On Wed, Apr 17, 2019 at 4:59 AM Nitish Saboo wrote: > > Made recommended changes to the file main.go.You can see the file in my > repository : https://github.com/nitishsaboo/Testing > > Now 'go build -x' is failing with the following error: > > WORK=/tmp/go-build838755651 > mkdir -p $WORK/b001/ > cd /home/nitish/Documents/goworkspace/src/forgithub > CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir > $WORK/b001/ -importpath forgithub -- -I $WORK/b001/ -g -O2 > -I/tmp/install/syslog-ng-3.6.2/ -I/usr/local/include/syslog-ng/ > -I/usr/local/include/syslog-ng/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ > -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ > -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ ./main.go > cd $WORK > gcc -fno-caret-diagnostics -c -x c - || true > gcc -Qunused-arguments -c -x c - || true > gcc -fdebug-prefix-map=a=b -c -x c - || true > gcc -gno-record-gcc-switches -c -x c - || true > cd $WORK/b001 > TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC > -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build > -gno-record-gcc-switches -I ./ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ > -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ > -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ > -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ -o ./_x001.o > -c _cgo_export.c > TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC > -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build > -gno-record-gcc-switches -I ./ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ > -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ > -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ > -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ -o ./_x002.o > -c main.cgo2.c > cd /home/nitish/Documents/goworkspace/src/forgithub > TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 > -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I > $WORK/b001/ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ > -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/compat/ > -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ > -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ > -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ -o > $WORK/b001/_x003.o -c syslog-node.c > > forgithub > > In file included from /usr/local/include/syslog-ng/apphook.h:28:0, > from syslog-node.c:3: > /usr/local/include/syslog-ng/syslog-ng.h:58:14: error: unknown type name > ‘gchar’ > extern const gchar *module_path; > ^ > In file included from syslog-node.c:3:0: > /usr/local/include/syslog-ng/apphook.h:40:37: error: unknown type name > ‘gint’; did you mean ‘uint’? > typedef void (*ApplicationHookFunc)(gint type, gpointer user_data); > ^~~~ > uint > /usr/local/include/syslog-ng/apphook.h:40:48: error: unknown type name > ‘gpointer’ > typedef void (*ApplicationHookFunc)(gint type, gpointer user_data); > ^~~~ > /usr/local/include/syslog-ng/apphook.h:42:32: error: unknown type name > ‘gint’; did you mean ‘uint’? > void register_application_hook(gint type, ApplicationHookFunc func, gpointer > user_data); > ^~~~ > uint > /usr/local/include/syslog-ng/apphook.h:42:43: error: unknown type name > ‘ApplicationHookFunc’ > void register_application_hook(gint type, ApplicationHookFunc func, gpointer > user_data); > ^~~ > /usr/local/include/syslog-ng/apphook.h:42:69: error: unknown type name > ‘gpointer’ > void register_application_hook(gint type, ApplicationHookFunc func, gpointer > user_data); > ^~~~ > In file included from syslog-node.c:5:0: > /usr/local/include/syslog-ng/tags.h:30:9: error: unknown type name ‘guint16’ > typedef guint16 LogTagId; > ^~~ > /usr/local/include/syslog-ng/tags.h:43:37: error: unknown type name ‘gchar’ > LogTagId log_tags_get_by_name(const gchar *name); > ^ > /usr/local/include/syslog-ng/tags.h:44:7: error: unknown type name ‘gchar’ > const gchar *log_tags_get_by_id(LogTagId id); > ^ > In file included from /usr/local/include/syslog-ng/gsockaddr.h:29:0, > from /usr/local/include/syslog-ng/logmsg.h:29, > from syslog-node.c:6: > /usr/local/include/syslog-ng/atomic.h:31:3: error: unknown type name ‘gint’ > gint counter; > ^~~~ > /usr/local/include/syslog-ng/atomic.h:40:15: error: unknown type name > ‘gboolean’ > static inline gboolean > ^~~~ > /usr/local/include/syslog-ng/atomic.h:46:15: error: unknown type name ‘gint’ > static inline gint > .. > .. > > Can you please guide me as in which library I a
Re: [go-nuts] cracking the go language aplication
Could you provide some more details on what it is you want to do? Are you looking to decompile a Go executable? On Wed, Apr 17, 2019 at 12:23 PM smn shilla wrote: > Hi all > Please anyone who know to crack the go application.exe please assist me > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Interaction between Modules and GOPATH
> So do *not* use go get when manually cloning the project then I take it? That is correct. For most developers it would be one or more repositories that contain many modules, not all of which would be go-gettable anyway. Also note that "go get" in module mode (outside of GOPATH) will unpackage with non-writable permissions to the local cache, as packages are not intended to be modified. Cloning the repo is the best way to get something you can work on. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Interaction between Modules and GOPATH
On 4/17/19 2:50 PM, andrey mirtchovski wrote: If you are fetching it with "go get" then that's presumably because it's a dependency required by another package or module, in which case the go command will use the correct place for it based on whether "go get" was run inside a module directory (then it goes in the module cache) or anywhere else (then it goes into GOPATH). If you are not fetching the project as part of a dependency, because you want to work on it, modify it, etc, then you can clone it anywhere outside GOPATH on your system and don't need to use "go get". One of the use cases for go modules was to allow projects to reside everywhere on the filesystem to allow legacy directory layouts to be used when developing. So do *not* use go get when manually cloning the project then I take it? -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Pointer based API and constants literals, how to best handle it?
Thanks Jim, and for the sympathy :) I'm almost tempted to use the REST API and bypass the SDK... I already implemented a missing Cognito Provider using the web API, and it seemed friendlier than this. It would be one less dependency too, since I'm deploying to AWS Lambda and I'm already at 14MB for my first Go based Lambda. Peter On Wednesday, 17 April 2019 21:29:31 UTC+2, Jim Ancona wrote: > > Having used the AWS SDK, I feel your pain. They do have built-in helper > methods, e.g. https://docs.aws.amazon.com/sdk-for-go/api/aws/#String, so > at least you don't have to define your own. > > Jim > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Interaction between Modules and GOPATH
> This is all fine and good until the project is fetched with a go get command, > which dumps everything directly into GOPATH, thereby preventing it from > fetching dependencies. If you are fetching it with "go get" then that's presumably because it's a dependency required by another package or module, in which case the go command will use the correct place for it based on whether "go get" was run inside a module directory (then it goes in the module cache) or anywhere else (then it goes into GOPATH). If you are not fetching the project as part of a dependency, because you want to work on it, modify it, etc, then you can clone it anywhere outside GOPATH on your system and don't need to use "go get". One of the use cases for go modules was to allow projects to reside everywhere on the filesystem to allow legacy directory layouts to be used when developing. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Interaction between Modules and GOPATH
I recently converted a project from residing under GOPATH + using a vendor/ directory, to using the new Module system. As I understand the system, and what I could discover from testing as I did the conversion, is that the two systems are mutually exclusive: using modules completely ignores vendoring unless forced by environment variable, and modules do not work under GOPATH. This is all fine and good until the project is fetched with a go get command, which dumps everything directly into GOPATH, thereby preventing it from fetching dependencies. What am I missing here? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Pointer based API and constants literals, how to best handle it?
Having used the AWS SDK, I feel your pain. They do have built-in helper
methods, e.g. https://docs.aws.amazon.com/sdk-for-go/api/aws/#String, so at
least you don't have to define your own.
Jim
On Wed, Apr 17, 2019 at 2:22 PM whitehexagon via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I'm still very new to Go, so apologies if this is obvious. I'm porting
> some code over to Go, and the provided SDK I'm working with seems to want
> pointers everywhere. However a lot of the values are constant / literals.
>
> So for example storing some data in the DB:
>
>
> https://docs.aws.amazon.com/sdk-for-go/api/service/simpledb/#PutAttributesInput
>
> My first thought was along the lines:
>
> field1 := ReplaceableAttribute{&"colA", &true, &"new value"}
> condition := UpdateCondition{&true, &"ColKey", &"Key"}
> input := PutAttributesInput{[]*ReplaceableAttribute{field1}, &"TABLE1",
> &condition", &"Key"}
>
> That was before reading a lot of historical debates about the merits of
> such syntax... So assuming I dont want to create vars for every value, or
> helper functions, Is there a clean way of achieving the above?
> I can see that the API provides convenience setters for every struct
> attribute, but you can imagine it creates a lot of code bloat for quite
> simple functionality. Any thoughts?
>
> Peter
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] cracking the go language aplication
Hi all Please anyone who know to crack the go application.exe please assist me -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Pointer based API and constants literals, how to best handle it?
I'm still very new to Go, so apologies if this is obvious. I'm porting
some code over to Go, and the provided SDK I'm working with seems to want
pointers everywhere. However a lot of the values are constant / literals.
So for example storing some data in the DB:
https://docs.aws.amazon.com/sdk-for-go/api/service/simpledb/#PutAttributesInput
My first thought was along the lines:
field1 := ReplaceableAttribute{&"colA", &true, &"new value"}
condition := UpdateCondition{&true, &"ColKey", &"Key"}
input := PutAttributesInput{[]*ReplaceableAttribute{field1}, &"TABLE1",
&condition", &"Key"}
That was before reading a lot of historical debates about the merits of
such syntax... So assuming I dont want to create vars for every value, or
helper functions, Is there a clean way of achieving the above?
I can see that the API provides convenience setters for every struct
attribute, but you can imagine it creates a lot of code bloat for quite
simple functionality. Any thoughts?
Peter
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Is it possible to lazy duplicate the underlying bytes for coversion []byte(aString) on demand at runtime?
On Wednesday, April 17, 2019 at 10:55:10 AM UTC-4, T L wrote: > > For a byte slice with a negative cap, when the followings happen, > a duplication should be performed and its cap should be changed to > positive: > * the elements of the slices are modified > * the slice is assigned to another slice, > * another slice is derived from the slice. > * the slice is used as the first argument of an append call and the number > of appended elements is zero. (an assignment in fact) > taking addresses of slice element will also trigger a duplication. > > > On Wednesday, April 17, 2019 at 4:11:50 AM UTC-4, T L wrote: >> >> The cap of the result slice of []byte(aString) is set to -realCap >> initially. >> An negative cap indicates the elements of the slice shouldn't be modified. >> When a modification operation on the result slice is encountered later, >> a duplication is performed and the cap of the slice is set to realCap. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Is it possible to lazy duplicate the underlying bytes for coversion []byte(aString) on demand at runtime?
On Wednesday, April 17, 2019 at 10:55:10 AM UTC-4, T L wrote: > > For a byte slice with a negative cap, when the followings happen, > a duplication should be performed and its cap should be changed to > positive: > * the elements of the slices are modified > * the slice is assigned to another slice, > * another slice is derived from the slice. > * the slice is used as the first argument of an append call and the number > of appended elements is zero. (an assignment in fact) > In fact, if, after the latter three operations, if the slice converted from a string is not used nay more, the duplication still needn't to be made. > > > On Wednesday, April 17, 2019 at 4:11:50 AM UTC-4, T L wrote: >> >> The cap of the result slice of []byte(aString) is set to -realCap >> initially. >> An negative cap indicates the elements of the slice shouldn't be modified. >> When a modification operation on the result slice is encountered later, >> a duplication is performed and the cap of the slice is set to realCap. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Is it possible to lazy duplicate the underlying bytes for coversion []byte(aString) on demand at runtime?
For a byte slice with a negative cap, when the followings happen, a duplication should be performed and its cap should be changed to positive: * the elements of the slices are modified * the slice is assigned to another slice, * another slice is derived from the slice. * the slice is used as the first argument of an append call and the number of appended elements is zero. (an assignment in fact) On Wednesday, April 17, 2019 at 4:11:50 AM UTC-4, T L wrote: > > The cap of the result slice of []byte(aString) is set to -realCap > initially. > An negative cap indicates the elements of the slice shouldn't be modified. > When a modification operation on the result slice is encountered later, > a duplication is performed and the cap of the slice is set to realCap. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] 紧急！！中国一线互联网公司招聘云容器GO研发技术Lead
中国一线互联网公司招聘云容器GO研发技术Lead，希望可以带领团队负责新的一代产品的研发，GO作为主要的技术语言，业务连年增长，薪资很有竞争力，有兴趣的朋友可以加我微信：1861392，详细沟通，谢谢！ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: fatal error: 'config.h' file not found
Hi Ian, Made recommended changes to the file main.go.You can see the file in my repository : https://github.com/nitishsaboo/Testing Now 'go build -x' is failing with the following error: WORK=/tmp/go-build838755651 mkdir -p $WORK/b001/ cd /home/nitish/Documents/goworkspace/src/forgithub CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/b001/ -importpath forgithub -- -I $WORK/b001/ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ ./main.go cd $WORK gcc -fno-caret-diagnostics -c -x c - || true gcc -Qunused-arguments -c -x c - || true gcc -fdebug-prefix-map=a=b -c -x c - || true gcc -gno-record-gcc-switches -c -x c - || true cd $WORK/b001 TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ -o ./_x001.o -c _cgo_export.c TERM='dumb' gcc -I /home/nitish/Documents/goworkspace/src/forgithub -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I ./ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ -o ./_x002.o -c main.cgo2.c cd /home/nitish/Documents/goworkspace/src/forgithub TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -I $WORK/b001/ -g -O2 -I/tmp/install/syslog-ng-3.6.2/ -I/usr/local/include/syslog-ng/ -I/usr/local/include/syslog-ng/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/compat/ -I/tmp/install/syslog-ng-3.6.2/lib/ivykis/ -I/usr/local/include/syslog-ng/ivykis/ -I/usr/local/include/eventlog/ -I/usr/include/glib-2.0/ -I/tmp/install/syslog-ng-3.6.2/modules/ -o $WORK/b001/_x003.o -c syslog-node.c forgithub In file included from /usr/local/include/syslog-ng/apphook.h:28:0, from syslog-node.c:3: /usr/local/include/syslog-ng/syslog-ng.h:58:14: error: unknown type name ‘gchar’ extern const gchar *module_path; ^ In file included from syslog-node.c:3:0: /usr/local/include/syslog-ng/apphook.h:40:37: error: unknown type name ‘gint’; did you mean ‘uint’? typedef void (*ApplicationHookFunc)(gint type, gpointer user_data); ^~~~ uint /usr/local/include/syslog-ng/apphook.h:40:48: error: unknown type name ‘gpointer’ typedef void (*ApplicationHookFunc)(gint type, gpointer user_data); ^~~~ /usr/local/include/syslog-ng/apphook.h:42:32: error: unknown type name ‘gint’; did you mean ‘uint’? void register_application_hook(gint type, ApplicationHookFunc func, gpointer user_data); ^~~~ uint /usr/local/include/syslog-ng/apphook.h:42:43: error: unknown type name ‘ApplicationHookFunc’ void register_application_hook(gint type, ApplicationHookFunc func, gpointer user_data); ^~~ /usr/local/include/syslog-ng/apphook.h:42:69: error: unknown type name ‘gpointer’ void register_application_hook(gint type, ApplicationHookFunc func, gpointer user_data); ^~~~ In file included from syslog-node.c:5:0: /usr/local/include/syslog-ng/tags.h:30:9: error: unknown type name ‘guint16’ typedef guint16 LogTagId; ^~~ /usr/local/include/syslog-ng/tags.h:43:37: error: unknown type name ‘gchar’ LogTagId log_tags_get_by_name(const gchar *name); ^ /usr/local/include/syslog-ng/tags.h:44:7: error: unknown type name ‘gchar’ const gchar *log_tags_get_by_id(LogTagId id); ^ In file included from /usr/local/include/syslog-ng/gsockaddr.h:29:0, from /usr/local/include/syslog-ng/logmsg.h:29, from syslog-node.c:6: /usr/local/include/syslog-ng/atomic.h:31:3: error: unknown type name ‘gint’ gint counter; ^~~~ /usr/local/include/syslog-ng/atomic.h:40:15: error: unknown type name ‘gboolean’ static inline gboolean ^~~~ /usr/local/include/syslog-ng/atomic.h:46:15: error: unknown type name ‘gint’ static inline gint .. .. Can you please guide me as in which library I am missing here and what needs to be done in this case? Thanks On Wed, Apr 17, 2019 at 10:48 AM Ian Lance Taylor wrote: > On Tue, Apr 16, 2019 at 9:56 PM Nitish Saboo > wrote: > > > > I am new to GO.Can I get little help on this ? > > It's really hard to know what the answer is. > > One thing you can
Re: [go-nuts] SHA256 with input not aligned to x8 bit
Personally I don't think so. It's a very niche use case AFAICS and I can't
find an implementation in any other language that allows you to calculate
the hash of an arbitrary number of bits. But this is just my point of view
- anyone is free to raise an issue if they like.
On Tue, 16 Apr 2019, 20:34 Skip Tavakkolian,
wrote:
> should this be entered into issue tracker?
>
>
> On Mon, Apr 15, 2019 at 11:38 PM roger peppe wrote:
>
>> Yes, you're right. As I said, my solution won't work if you need to
>> interoperate with other implementations.
>>
>> It's interesting that the SHA256 standard is defined to work on an number
>> of bits though. I wasn't aware of that.
>>
>> I had a look around and I didn't find any other language's SHA256
>> implementation that allows input which isn't a multiple of 8 bits. Are you
>> aware of one? Which implementation are you needing to interoperate with
>> that does allow this?
>>
>> ISTM that if you do require this, it wouldn't be too hard to copy the
>> existing implementation and change the digest.checkSum method so that it
>> could pad from an arbitrary number of bits.
>>
>> cheers,
>> rog.
>>
>>
>> On Mon, 15 Apr 2019 at 20:52, Paolo C. wrote:
>>
>>> Thanks Rog for the answer.
>>> But that won't work.
>>> SHA-256 is a standard (FIPS180-4) and if one uses it, is for
>>> interoperate in most cases.
>>> It may happen that you need only to hash 8bit bounded streams, but it
>>> also may not be the case. So, any implementation should be careful of being
>>> correct.
>>> You example is flawed for the reason the if you WRAP the original
>>> algorithm, it will anyway 'Finalize' your input padding it again (look at
>>> the Sha256 code), so, the checksum that you will obtain will not match with
>>> the one of some who has correctly implemented the standard.
>>> On the other hand, if your example worked, it would mean that for each
>>> 'odd bitted' stream (i.e. 12 bits) there is a sequence that can be
>>> deterministically calculated adding a couple of bytes that has the same
>>> sha256. This would the demonstration that sha256 is broken.
>>> To obtain a correct implementation you should grab the sha256.go code
>>> and bring into your own package correcting the limitation, but this has the
>>> problem of the usage of some internal packages, which in turn complicates
>>> everything. And also change the interface hash.Hash to let it be usable in
>>> hmac, for example.
>>> Anyway, don't let me be misunderstood, I can live with it, simply I
>>> trusted the package declaration
>>>
>>> // Package sha256 implements the SHA224 and SHA256 hash algorithms as
>>> defined
>>>
>>> // in FIPS 180-4.
>>>
>>> that revealed partially true. Technically speaking it's not a BUG, because
>>> since I can NOT input spare bits, I will never obtain wrong results. But
>>> for sure it's not a full and correct implementation.
>>>
>>> Paolo
>>>
>>> On Monday, April 15, 2019 at 11:48:23 AM UTC+2, rog wrote:
The answer depends on what why you want to do this. If you don't need
to interoperate with some other party that needs to arrive at the same
checksum, you could write your own wrapper around sha256 that adds the
necessary information to specify how many bits are significant. Something
like this, perhaps:
// hashBits returns a hash of the first nbits bits of b,
// starting at the most significant bit of the first
// byte of b.
//
// So hashBits([]byte{0x5a, 0xbc, 0xde}, 12) would
// hash 0x5ab, ignoring the final 0xcde.
//
// It works by hashing an extra 2 bytes that encode
// the final bits and how many there are.
//
// hashBits will panic if nbits is greater than len(b) * 8.
func hashBits(b []byte, nbits int) [sha256.Size]byte {
oddBits := nbits & 7
blen := nbits >> 3
b1 := make([]byte, blen+2)
copy(b1, b[0:blen])
if oddBits > 0 {
b1[blen] = b[blen] & ^(0xff >> uint(oddBits))
b1[blen+1] = byte(oddBits)
}
return sha256.Sum256(b1)
}
Note that the code above is almost untested, and there are probably
more standard ways to do it - that was just the first thing that came into
my head.
cheers,
rog.
On Sun, 14 Apr 2019 at 22:02, Paolo C. wrote:
> SHA256 (SHA in general) has a precise behavior if you wanna hash a
> number of bits not multiple of the block (512bit)
> Sha256.go handle this correcty ONLY in the case that you input is at
> least multiple of 8 bits.
> If you wanna hash, say, 20bit (0xABCDE) you cannot obtain a correct
> result.
> Note that Sha256(0xABCDE) is (See FIPS and NIST publications) not the
> same
Re: [go-nuts] Current Thinking on Explicit Memory Freeing?
There are two issues here: 1. *"I'm done with this and I want to free it now."* It seems helpful as a programmer to say such things. I wanted that once. The problem with it is that the runtime can't trust you if you say it. At best it can put the address on a list to be examined, but only a GC pass will be able to prove that the region is unreferenced. 2. *"It is still referenced but I'm done with it forever."* This is good in spirit: it is a kind of program-level pointer liveness analysis as is done in register allocation. It could be proven by the compiler that at line N+1 of code...some things from lines 0..N will no longer be referenced. This could be done automatically by inserting "set never to be referenced pointers to nil" code during compilation after each provable last reference. On Tue, Apr 16, 2019 at 10:22 PM Ian Lance Taylor wrote: > On Tue, Apr 16, 2019 at 9:53 PM wrote: > > > > In a compiler, say during the lexing and parsing phases, memory might be > allocated > > that won't be needed after those phases are complete. The memory is > still referenced, > > so the GC won't free it, but conceptually it actually could be freed. In > other words, > > the fact that memory is referenced isn't the final word on whether it > could be freed. > > If the memory is still referenced, it can still be used, so it won't > be freed. If the memory will not longer be used, then don't reference > it. > > > > You're saying to modify all the pointers that point to this memory. I'm > guessing > > that this could be a lot of work, Plus, let's say this memory is > organized as > > a linked list. Would it be sufficient to just modify the pointer that > points to the > > head of the list, or would I have to go through the list from tail to > head, modifying > > the pointers in each list element? > > As Robert said, just stop referencing the head. The only references > that count are the ones from global and local variables. If it can't > be reached by following pointers from a variable, then it is no longer > referenced. > > > > And to answer Robert Engels question - no, I'm not concerned with the > > GC's performance because the memory I'm thinking about won't be seen > > by the GC since it's still referenced. And yes, I'm wondering whether > there's > > a way to create a region-like entity so that all the memory that was > allocated > > in the region could be freed in one swell foop. > > My earlier answer still stands: such a region is unlikely to make a > significant difference in a GC system. > > Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com * -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Is it possible to lazy duplicate the underlying bytes for coversion []byte(aString) on demand at runtime?
The cap of the result slice of []byte(aString) is set to -realCap initially. An negative cap indicates the elements of the slice shouldn't be modified. When a modification operation on the result slice is encountered later, a duplication is performed and the cap of the slice is set to realCap. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
